自動生成を活用した、運用保守コストを抑える Error/Alert/Runbook の一元集約管理 / Centralized management of Error/Alert/Runbook to minimize operational costs using automated code generationDevOpsDays TOKYO 2024 の登壇資料です。 https://confengine.com/conferences/devopsdays-tokyo-2024/proposal/19703/erroralertrunbook-centralized-management-of-erroralertrunbook-to-minimize-operational-costs-using-automated-code-generation
Dockerコンテナ化したJavaアプリのヒープのサイズ調整オプションの検証 - Qiita
はじめに こんにちは。私は弊社で企画・運営している、Dot to Dotという個人の同意の元に様々なデータを連携することができる分散型データ連携プラットフォームの開発・保守を担当しています。 Dot to Dotではデータ連携をしたい事業者向けに、データ連携用の通信モジュールを、Spring Bootを使用したJavaアプリケーションとして作成したDockerイメージ形式で配布しています。 昨今ではDockerでアプリケーションを実行するのが当たり前の風潮になりつつありますが、実際に本番で適用する際に必要なチューニングの話はあまり聞かないかと思います。 そこで本記事では、JavaアプリケーションをDockerコンテナで運用する場合に必要な、ヒープのチューニングについて説明します。これからJavaアプリケーションをDockerコンテナ化して運用したい人や、すでに運用中でもヒープチューニングし
PagerDuty Incident Response Documentation
Home Being On-Call Before an Incident During an Incident After an Incident Crisis Response Training Additional Resources Getting Started On-Call Being On-Call Who's On-Call? Alerting Principles Before an Incident What is an Incident? Severity Levels Different Roles Call Etiquette Complex Incidents During an Incident During an Incident External Communication Guidelines Security Incident After an In
OpenZipkin · A distributed tracing system
Zipkin Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in service architectures. Features include both the collection and lookup of this data. If you have a trace ID in a log file, you can jump directly to it. Otherwise, you can query based on attributes such as service, operation name, tags and duration. Some interesting data will be sum
AWSコスト削減とリソース管理 | 外道父の匠
クラウド使いなエンジニアの皆様、猛暑と円安の中いかがお過ごしですか。上層部からインフラコスト削減を突きつけられてはおりませんでしょうか。 今回はおそらく初めてコスト削減についてAWSを軸に書いていきますが、考え方はどこの環境でも似たりよったりなので何かしらの足しになればと思う次第であります。 目次 長いです。ひきかえしたほうがいいぞ！ コミュニティに捧げます AWSの売上 コスト削減とは 三大使命 コスト状況整理 Load Balancer 参考リンク 統合による削減 EC2 Autoscaling 参考リンク 情報整理 古いインスタンスタイプの変更 スケジュールの調整 スポットインスタンスの適用 軽量インスタンスの統合・サーバーレス化 アプリケーション処理の軽減 EC2 EBS EBSは高い 不要EBSを削除・スナップショット化 ボリュームタイプの変更 EC2 AMI NAT Gatew
DBマイグレーションツールのロールバック機能は使うな - モヒカンメモ
データベースマイグレーションツールのロールバック機能は安全に使えないので使うべきではないと思う。 ロールバック機能 RDBMSのデータベーススキーマを管理するためのツールとして flyway や、ウェブアプリケーションフレームワーク組み込みのマイグレーションツール (例: Laravel Migration ) がある。 DBマイグレーションツールにはマイグレーションを進める (up) 機能のほかに、進めた変更をロールバックする (down) 機能がついている。 マイグレーションを進める例: CREATE TABLE customers ( id INT PRIMARY KEY, name VARCHAR(50), email VARCHAR(100) ); マイグレーションをロールバックする例: DROP TABLE customers; この記事では、ロールバックする (down) 機
運用出来るWebアプリケーションの作り方
はじめに 先日、下記のようなツイートを見つけて、そういえば趣味で個人開発してたときには然程気にしてなかったけど、仕事で運用するようになって先輩たちから学んだり自分で身につけたチップスってちょこちょこあるよねー、とふと思ったので、Webアプリケーション開発に関わるものをいくつかまとめてみました。 特に体系的/網羅的という程でもないですし、最近はFWや色々な仕組みでカバーされてるものも多いですが備忘録として。 Tips 機械が読めるログを作る これは割と重要なのですが、ログは人間が読むものではなく機械が読むものです。それはZabbixだったりDatadogだったりSplunkだったりgrep/awkだったりツールは何でも良いのですが、古の時代はさておき現代ではログは機械が読めることが最重要です。 まず大前提として構造化されている必要があります。言うまでもないですが「フリーフォーマット」のログの
DBマイグレーションを行う技術 - 発明のための再発明
データベースのスキーマを変更するということはデータをいじる行為であり、最悪の場合データが消えます。 最悪の事態にはならなくとも、思わぬ場所に影響が起きたり、データの不整合が発生する恐怖と戦う必要が有ります。 テストや切り戻しを含めて計画し、大きな変更の場合にはダウンタイムまで考慮する必要があります。 そこで、RDBを対象にデータベースの変更を行う方法について書いていきます。 スキーマ変更 まずは、スキーマ変更について、 カラムを追加する 一番簡単で、影響も少ない変更です。 気をつけるのは、 ソースコードの変更よりも前にスキーマ変更を完了させる (長時間)ロックがかからない方法を選ぶ といったところでしょうか。 大抵の場合は、スキーマの変更とソースコードの変更の順番にさえ気をつければ問題は発生しません。 カラム名を変更する 「ALTER」でさくっと変えたくなりますが、ソースコードの変更が同時
AWSの開発環境の利用時間をGoogleカレンダー連動させたら開発チームが自由に使えてコスト70%削減！！ - Uzabase for Engineers
こんにちはNewsPicks SREチームの美濃部です。 NewsPicksのSREのミッションの1つに「コストを適正化する」というものがあります。サービスの規模拡大に比例してインフラコストが増えないようにし、売上に対するコストの割合を低く維持していくのがミッションになります。 今回はこのミッションに対するアクションとして開発環境のインフラコストを適正化した話をします。 NewsPicksの開発環境について 開発環境のコストをどうやって適正化したか 稼働時間対応を実現する仕組みについて 実際どれくらい削減できたのか まとめ NewsPicksの開発環境について まず、NewsPicksの開発環境について概要を説明します。 インフラ基盤は本番環境と同様にAWSを利用しており開発チームは現在10以上のチームが存在し、それぞれのチーム専用に用意された開発環境を利用しています。 2年程前までは開発
Feature Toggles (aka Feature Flags)
Feature Toggles (often also refered to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it's important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practice
ヘルスチェックの実装
サービスはあらゆる種類の信頼性と復元力を組み込んで設計できますが、実践的な信頼性を実現するためには、予測可能な障害が発生したときの対処策も欠かせない要素となります。Amazon では、ハードウェアは最終的には機能しなくなるように設計されているため、水平方向にスケーラブルで冗長なサービスを構築しています。どのハードドライブにも最大予想寿命があり、ソフトウェアのどの部分もある時点でクラッシュする可能性があります。サーバーの正常性はバイナリのように見える場合があります。動作するか、まったく動作せず、正常に機能しないかのどちらかです。ですが、そうではありません。障害が発生したサーバーは、シャットダウンするだけでなく、予測できないか、場合によってはシステムへ不均衡な損害をもたらす可能性があります。ヘルスチェックは、これらの種類の問題を自動的に検出して対応します。 この記事では、ヘルスチェックを使用し
障害報告書を書こう！ - Qiita
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
LINEの大規模なData PlatformにData Lineageを導入した話
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog はじめに こんにちは、Data Platform室IU Devチームの島村です。 Data Platform室では、約400ペタバイトのデータ分析基盤を運用しております。このData Platformは、「Information Universe」(以下、IU) と呼ばれており、LINEの様々なアプリケーションから生成されるデータをLINE社員が活用できるように、データの収集、処理、分析、可視化を提供しています。私が所属するIU Devチームでは、「IU Web」を開発しています IU Webは、IUのデータを安全にかつ効率的に活用できるようにするData Catalog機能を提供しており、LINEグループのあらゆるサービスか
「システム運用アンチパターン」を一読したので、その要点（特に薦めたい感想5点） - Qiita
システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション | Jeffery D. Smith, 田中 裕一 |本 | 通販 | Amazon エンジニアがDevOpsで解決する組織・自動化・コミュニケーション。早速お薦めしたく書いています。読書感想文です。 感想5点 良いぞ。周りに薦めたい 百聞一見。目次だけでも: https://www.oreilly.co.jp/books/9784873119847/#toc 特に自分にとって良かったのは以下 9章 せっかくのインシデントを無駄にする 10章 情報のため込み：ブレントだけが知っている だが、一番スゴイのは11章かもしれない 「文化を変えようと思うのであれば、文化がどのように共有されているかを理解すること」 コロナ以前は 議事録 会議 机横での雑談 飲み会 タバコなどなどあったが コロナ以降、リ
システム運用アンチパターン
上層部がDevOpsに理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームにDevOpsを導入するための現実的な方法を紹介します。 重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。 組織で必要とされる変化を、エンジニアが行動することで実現する本書は、ソフトウェアシステムをよりよく開発運用したいエンジニア必携の一冊です。 目 次 序文 本書について 1章 DevOpsを構成するもの 1.1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
All release notes in one place
あんどぅ on Twitter: "本番運用するといずれ誰もがたどり着く、公式ドキュメントには書かれてないログ管理の現実解が資料化されていてすばらしい そう、CloudWatch LogsにはDev環境 or ERRORの場合のみ飛ばすFluentdの設定をすることで利便性と料金のバランスをとるのである これは公式ドキュメントにすべき https://t.co/RE4FmPCpJX"
GitHub - k0kubun/sqldef: Idempotent schema management for MySQL, PostgreSQL, and more
非ITの事業会社にSREと言わずにSREを持ち込んだ
