Category
ベストプラクティス

私の名前はJoshua Carnide、Waterloo大学でソフトウェアエンジニアリングを学ぶ4年生です。この記事で、私がPagerDutyのトロント事務所でのインターンシップで得た素晴らしい経験と、それが成功のためにどうに役立ったかをお伝えしたいと思います。

私はPagerDutyのAndroidとiOSアプリケーションの維持と改善を担当するモバイルチームのメンバーでした。このチームの目的は、移動中にユーザーがPagerDutyプラットフォームとシームレスにやり取りできる機能を提供することです。小さなチームだったけど急速に成長していたチームでした。2018年1月に参加したとき、このチームにはわずか5人しかいませんでした。 3ヵ月後、2人のエンジニアリングインターン（私を含む）、製品管理のインターン、5人の常勤デベロッパー、アジャイルコーチ、製品オーナー、エンジニアリングマネージャーの計11人に増えました。 私はここでの4カ月間に想像していた以上に多くのことを学び、信じられない才能を持つ多くの人と出会い、エンジニアとして大きく成長できました。

PagerDutyの人々：多様性と包括性

PagerDutyの人々は驚くべき人ばかりでした。 彼ら自分の製品と彼らが行う仕事について心からの情熱を持っています。ユーザーに最高の経験をしっかりと提供し続けて、その合間に楽しい時間を過ごすために働いています。

PagerDutyは、多様性と包括性を強く信じる個人のコミュニティでもあります。他者との違いを受け入れる環境であり、あなたが本来のあなた自身であることができる場所です。例えばInternational Women’s Dayの日、同社のトロントオフィスでは、SalesforceやProcter＆Gambleなどの4人の地元の女性のプロフェッショナルを招いたディスカッションパネルを開催しました。私にとって他のジェンダー指向と比較した女性のキャリアパスについて深く知ることができ、さまざまな職業の女性が直面している現代の課題を知ることができる貴重な機会でした。

PagerDutyにいた時、私はインターンだと思ったことはありません。いつもフルタイムの従業員の一人のように感じました。 インターンシップの最初の1週間に、カリフォルニア州ナパバレーで開催された会社のキックオフ（ Company Kick Off ：CKO）イベントに参加する特権を得ました！　CKOは、シドニー、ロンドン、シアトル、トロント、サンフランシスコのオフィスなど遠隔地の従業員が一緒に来て、PagerDutyの成功を祝い、新年に向けての重要な優先事項に認識を合わせる機会でした。このイベントには多くのソーシャルな機能があり、さまざまなチームや世界各地の人々と出会う機会がありました。サンフランシスコのオフィスで働いているモバイルチームのメンバーにも会いました。会社のさまざまな従業員の背景や経験について学ぶことは本当にクールでした。PagerDutyの一人ひとりがユニークで特別なものをその場に持ち寄っていたのです。

CKOの中のあるソーシャルイベントに参加したモバイルチームと私。 （私は左の後ろの列にいます。）

メンターシップ

インターンシップの初めのうち私は人に助けを求めることを躊躇しました。他の開発者を邪魔（bugging）したくなかったからです。しかし、そのうちにすぐ、彼らが人を助けるのが大好きで助けを求められるのも大歓迎なんだということに気づきました。そして問題を解決するためにペアリングすることがどれほど有益であるかも分かりました。

以前のインターンシップでは、私はAndroidの開発だけを行っていました。 だから私が初めてiOSのタスクを割り当てられたときには、iOSアプリケーションで作業したことがなかったし、Swiftプログラミング言語の経験がないので、随分緊張しました。 タスクはモバイルアプリのライブアップデートに関連するものでした。リアルタイムでコンテンツを動的に更新する新しいアプリの機能です。 この機能の基盤はすでにアプリに入っていて、あまりにも多くのコードを必要ではなかったし、かなり簡単な作業でしたが、どこから始めるべきかはわかりませんでした。

私が助けを求めたときに受けたサポートには驚きました。私はチームのフルタイムの上級iOSエンジニアとペアを組んで一緒にソリューションを作りました。途中で、Swiftの複雑さとiOSフレームワークの基本についても立ち止まり議論しました。その中でPagerDutyアプリについてのベストプラクティスと共通のパラダイムとデザインの決定などの話もしました、

加えて、私は途中で多くの有益な指導をいただきました。私たちのモバイルアプリケーションは、学習曲線が急に上を向く強力なライブラリやテクノロジーを利用しています。それでも私のチームメンバーは、私に手を差し伸べるためには喜んで自分の手を止めてくれました。 時間がをかけてなぜ何かがそのようになったかという理由を説明してくれましたし、何かを改善したり最適化したりできるかどうかを議論することには常にオープンでした。

さらに、私はインターンだったので、何をどうすべきかを決定する際に主導権を持つ（”call the shot”な）ポジションにあるとは思っていなかったのですが、間違いでした。 1か月以上経った後、私はフルタイムのAndroidエンジニアと共同で、テストのしやすさとスケーラビリティを向上させるためにAndroidアプリケーションをどう再構築すべきかという提案書を作りました。チームとして、私たちはどのアーキテクチャを使うかを決めましたが、私たちのアプリケーションにどう適用するのかは決まっていませんでした。 私は私たちのアプリにアーキテクチャを統合する方法の技術的な詳細を書き上げる責任がありました。それは重い責任でしたが、そのチャレンジを進んで引き受けました。他の開発者からの徹底的な見直しを受けてから、この提案は最終的に承認され、現在は私たちのアプリの標準として機能しています。

提案を完全に実行するプロセスには長い時間がかかります。 しかし、我々は、新しいアーキテクチャの基礎とそれで実装されるすべての新機能を定めました。 PagerDutyのAndroidアプリの未来に革命を起こすために私が大きな役割を果たしたと分かるのは素晴らしいことです。

小さなチームで大きなインパクトを

相対的に言えば、モバイルチームはPagerDutyの他のチームと比較してまだ小さいです。 小規模なチームとしては自律的にやれることがたくさんありました。たとえば、私たちのアプリで使用すべきコードアーキテクチャーに至るまで、プルリクエストの形式のような単純なものを理解することは、私たちの責任でした。 私たちは、アプリケーションのリリース時期や頻度を自分たちで決めました。チームはこのプロセスを非常に大事にしています。まずPagerDutyの従業員に新しいバージョンのアプリケーションを配布して、そののちに最高品質のアプリがユーザーに提供されるようにします。 チームの上級エンジニアと数回ペアを組んで、モバイルアプリをユーザーにリリースしました。 この経験から、多数のユーザーにアプリを出荷するプロセスについての洞察が得られました。すべてを円滑に進めるためにリリースを監視する方法を学びました。

成長の機会

PagerDutyには、パイプラインにたくさんのクールなプロジェクトがあり、どれもオフリミットはありません。 私が最初にPagerDutyに入社したとき、私はiOS開発やバックエンド開発をしたいという希望を出しました。 私は両方の仕事をする機会を与えられただけでなく、すぐにユーザーに出荷される重要なプロジェクトに取り組ませていただきました。

新しいことを学べたもう1つの非常に便利な機会は、モバイル・チームの週1回の共同作業セッションでした。そこではチームメンバーが個人的な開発にとって価値のあるものに取り組みます。 何か新しいことを探求し、疑問があるときはいつでもチームの上級開発者のサポートを受けるのは本当に便利なチャンスでした。私はこの時間を使って技術的知識を広げました。Swiftについてより深く学び、さらにiOSフレームワークについて学ぶために小さなiOSアプリケーションを開発しました。

私はアジャイル手法についても学びました。これは私のワークフローを実際に改善しました。 モバイルチームに参加したとき、彼らはScrum Agileメソドロジーを採用していました。 基本的に、これは、チームがスプリントと呼ばれる固定された時間単位で作業を完了するよう計画することを意味しました。私たちのチームにとっては、各スプリントは2週間の長さでした。 各スプリントの終わりに、私たちのチームは一緒になって（ れとろすぺくてぃと呼びます）スプリントについて議論しました。何がうまくいったのか、あまりうまくいかなかったのか、プロセスを改善するためにどんな行動が可能だったかを議論したのです。

これらの実践の中で、ボトルネックを特定して修正する方法と、他の開発者と効果的に連携する方法を学習しました。私が最初に会社に入社した時と比べると、自分が高品質の仕事を完成させようとしている間にスループットが大幅に増加したことにはっきりと気づきました。 もう一つのことも気が付きました。つまりPagerDutyが真剣に取り組んでいることは、皆の意見が重要であることと、レトロスペクティブは、各チームメンバーがチーム全体としてどのように改善でき、皆の提案が考慮されたかにというフィードバックを提供する機会であったことです。

未来に

全体的に見て私のPagerDutyでのインターンは最高の経験でした。 インターンシップが終わり、学校に戻ることは辛かったです。幸運にも多くの素晴らしい人と出会って、これからも続くたくさんの関係を築けたと感じています。 私は、自分がインターンシップの過程で獲得したスキルセットが、将来のエンジニアリングの取り組みに役立つと確信しています。 PagerDutyとモバイルチームと過ごした期間は、私にとって決して忘れられない経験です。

PagerDutyで働くことに興味がある場合は、キャリアページ（訳注：米国PagerDutyサイトの応募ページにリンクしてあります）に応募することを検討してください 。

本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

ConfigurationからScheduleを選択します。

「New On-Call Schedule」で新しいスケジュールを追加できます。

まず、 「Time zone」を日本に設定して、Layerを追加していきます。

レイヤーを順番に設定していきます。

レイヤー１では、1人の担当者が日中の時間帯に交互に担当するよう設定してみました。

レイヤー２では、それ以外の時間帯を2名で設定してみました。

最終的なスケジュールは、以下になりました。

簡単なUI操作だけで、柔軟なスケジュール設定ができますね。

また、スケジュールのOverride機能を使うと例外的なスケジュールも組み込むことができるので、非常に便利です。

PagerDutyで私達は個人としてもチームとしても日々勉強に励んでいます。具体的には、事後分析、コードレビュー、過去の見直し、SlackやJIRAでの議論、ヘルスチェック調査などです。さらに、インタレストグループに参加したり、スプリントレビュー、テクニカルトーク、ブログを読いんだり書いたりする機会もあります。

エンジニアとして、私たちは非効率なコードをリファクタリングし、技術的な欠陥に対処し、ワークフローを改善しようともしています。このように多くの仕事をしている（これとは別のスクラムチームでやっている製品やインフラストラクチャの仕事もある）ので時間をどのように管理するかが重要です。たとえば、どのプロジェクトが他のプロジェクトより優先されるべきか、その理由は何か？ 目標に向かってより効果的に進めるため、私たちは何をすべきか？

これらの質問に答えるには、当面の仕事のレバレッジを評価する必要があります。Edmond Lauの効果的なエンジニアによるとレバレッジとは「投下された時間当たりの生成された価値またはインパクト」というシンプルな方程式で定義されています。

言い換えれば、ハードに働くことは効果的に働くことと同義ではありません。それは仕事が生産的なのか、ただ忙しくしているのかの違いです。それを知るための別の方法は、エンジニアリングのROIです。私たちが取り組むべき仕事は無限にありますが、私たちの時間とリソースは限られています。効果的であるということは、最小の努力で最大の価値を生むものに取り組むことを意味します。「結果の80％は20％の労力から生まれる」―Pareto Principleとも呼ばれる80-20のルールが当てはまります。

どうすればレバレッジを高めることができるか

元IntelのCEOであるAndrew Groveは著書「High Output Management」で、レバレッジの総量―時間単位で生産する価値―を高めるためには、3つの方法しかないとしています。

一定の活動を完了するのにかかる時間を短縮する 特定の活動のアウトプットを増加させる レバレッジがより高い活動に移行する

日中は、会議、メールのチェック、Confluence／コメント／ブログの読み書き、Githu／Confluenceへのフィードバック、Slackディスカッションへの参加、デザインスプリントなど、さまざまな活動が行われています。しかし、あなたが何をしているのかに関わらず、あなたのレバレッジを向上させるために次のことを自問してみましょう。

どうすればこの活動を短時間で完了できるか どうすればこの活動によって生み出される価値を高められるか より高い価値を生み出せるものが他にあるか

以下にいくつかの例を示します。

ミーティング

会議をより効果的にするために、以下の質問について考えてみてください。

この会議に1時間かける必要があるか。30分で済ませられないか。それとも15分内のほうがいいか 会議の目的を全員が理解しているか。出席者は何か準備する必要があるか。彼らは事前に何かを読んでおくべきか この会議は必要なのか。Slackやメールですませられないか

電子メールとSlackのチェック

メールとSlackの設定は個人ごとに異なります。メールのチェックと返信に価値があることは否定できません（Slackのメッセージを読み、アップデートし、コラボレーションすることも同じ）。だが、これらはどんな点でそのリターンを低下させているのか。言い換えれば、これはいつから私たちの生産性の阻害要因になったのでしょうか。

1日を通して絶えず割り込みがかかる中で、この競り人の速さでコードを書けるマインドセットを持つことは難しいかもしれません。たとえば、私はコミュニケーションツール（メール、Slack、JIRAなど）で頻繁にチャットをしながら、Command + Tabでアプリケーション間を行き来したり、Chromeののタブからタブへとスイッチしたり、そしてコードを書いたりと、落ち着かない働き方をしています。しかし、私は正面を向いてロックインし、レーザーのように集中できる割り込みなしのコーディング時間―私が言うところのディープワークを、1日に少なくとも2〜3時間取れるようにしています。

Deep Workの著者であるCal Newportは、それを次のように定義しています。

「途切れのない十分な集中力で行われる専門的な活動は、認知能力を限界まで押し上げる。その努力は新しい価値を創造し、スキルを向上させる。それは簡単には真似できない」

私はまた、心理学者Mihaly Csikszentmihalyiによって造られたflowと呼ばれるコンセプトを聞いたことがあります。flowを経験した人々は、flowのことを「何の努力もせずに、時間の感覚や自己の存在、自分の問題も忘れるほど集中できる状態」と表現しています。

ディープワークをしている時、私はSlackのスヌーズ機能を使用しています。これで設定した時間は通知が抑制されます。その後、きりのいいところで何も起こっていないことを確認するため定期的にSlackをチェックします。

エンジニアは最大限仕事を頑張って、効果的な結果を果たしていると私は信じており、人には1日に少なくとも1時間か2時間は仕事に集中し、より生産的であるかを確認するよう勧めています。この時間を通常の集中していないコーディング時間と混同しないでください。理想的には、私たちは一日中コードを書くべきですが、散漫で集中していないコーディングと中断のないコーディングとは違います。私がディープワークと言う時は、途切れることのないコーディングを指します。

あなたが作業している現在のJIRAチケット

Jiraチケットがすでにプロダクトオーナーによって優先順位付けされており、ストーリータイムとスプリント計画プロセスを経ていると仮定すれば、それをもう一度見て、そのレバレッジを高めることができるかどうか考えましょう。次の3つの質問でそれをチェックしてみましょう。

どうすればこの活動を短時間で完了できるか 既存のライブラリを利用できるか。エンジニアにとって最初からスクラッチでコードを書くことが魅力的であることは私も知っています。 どうすればこの活動によって生み出される価値を高められるか より高い価値を生み出せるものが他にあるか

現在の目標やリリースのためもっと重要な作業が必要なのか。このような状況ではMVP （最小限の実行可能な製品）を考える―初期のフィードバックを収集しようとしているときに、最初からこのファンシーな最適化が本当に必要なのだろうか。リリース可能な最小スライスは何か。リリースにおける80-20とは何か。しないでいいのは何か。どのようにして価値を下げることなく範囲を縮小できるのか。

忙しい仕事に巻き込まれるのはよくあると思います。しかし、私は正しい質問を自分に問うことを覚えました。そうすれば効果的に仕事をして生産性を高めることができるでしょう。

次回は優先順位付けの方法についてより詳しく説明します。お楽しみに。

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

マネージドDNSプロバイダーからメトリックを収集して変換するためのツールをオープンソース化して皆様とシェアできたことを喜びに思います。私たちは現在DNSmetricsを使用して、SREチームの監視、警告システムに標準形式のデータ提供を行なっておりますが、この方式が皆さんのお役にも立てると信じております。

DNSの主な役割

PagerDutyでは、サービスの信頼性と可用性を重視しております。可用性は私たちの内部インフラの設計に重要であるだけでなく、私たちが所有していないインフラにも同じ要件を適用する必要があります。 PagerDutyは外部のプロバイダーをいくつかの不可欠なインフラコンポーネントに活用しています。本日はこれらの1つについて説明します。

ドメインネームシステムは、pagerduty.comのようなドメイン名を、APIやWebアプリケーションが要求する数字のネットワークアドレスに翻訳します。アドレスは変わる可能性があるため、ほとんどのシステム（とほとんどの人）は数字ではなく名前を使用します。そのため、私たちのドメインの DNSが利用できない場合、多数のお客様は私たちのサービスに到達できなくなるので、DNSを使用可能にして正しく構成することが重要です。

DNSプロバイダはこれを理解し、高可用性システムのグローバルネットワークを維持しています。しかし、DNSの性質上、大規模なシステムは間違いなくDoS攻撃の影響を受けやすくなります。実際、有名なマネージドDNSプロバイダの大部分は、過去数年間に少なくとも1つの大きなサービスの混乱を経験しています（例：1、2、3、4）。PagerDutyは過去に単一のプロバイダを使用していましたが、我々はもはや十分に頑強であるとは言えません。現在ではアクティブ―アクティブ構成（各プロバイダーが運用トラフィックの半分ずつを担当する）で、DNSニーズに対して2つのプロバイダーを使用しています。

DNSメトリックを何のため構築し、どのように役立つのでしょうか

両方のDNSプロバイダに監視と警告を設定するのは難しいことでした。各プロバイダは、管理インタフェースでオーバービューとレポートを提供していますが、公開されているメトリックの選択、異なるインタフェース内の同じデータの場所、平均とレポートに使用される時間間隔など、レポートはプロバイダによって異なります。プロバイダやゾーン全体でDNSの状態のスナップショットを得るために多くの努力とさまざまな表示画面が必要で、我々はアラート機能のために自らのツールを使用したいと考えました（いずれのプロバイダーも当社の総トラフィックの一定割合以上を取得していないことを追跡します）。

私たちにはもっと良い解決策が必要でしたが、利用可能なものはなかったので、構築することにしました。これは、APIを使用して両方のDNSプロバイダに接続し、関心のある指標を引き出すサービスです。これらのメトリックは、同じ名前空間とユニットに正規化され、標準的な統計形式で発行され、任意の時系列モニタリングシステムに取り込まれます。

2つの異なる管理インターフェイスとそれぞれの複数の画面ではなく、すべてのプロバイダとゾーンを集約したDNSの正常性の概要を示す単一のダッシュボードが作成されました。

さらに、時系列のメトリックを1か所に配置したので、時系列クエリ（我々の場合はDataDogモニタ）の豊かな表現力を適用して、すべてのプロバイダでDNSの柔軟なアラートをプロバイダごと、ゾーンごとに設定できます。

マネージドDNSプロバイダを監視することは、PagerDutyのSREチームだけの問題ではありません。そのため、オープンソースのDNSメトリクスを採用することにしました。現時点では、使用しているプロバイダのみをサポートしていますが、他のプロバイダにカバレッジを拡張するには、一般的に使用されているメトリックを公開するREST APIがあれば簡単です。 DNSメトリックを試してみるのは、Dockerコンテナを実行するのと同じくらい簡単です。スピンを加えて環境内の場所を探すこともできるかもしれません。

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

800人のITプロフェッショナルの調査結果から驚くべき発見

PagerDutyで、私たちは芳しくない業務の健全性につながる否定的な結果を認識しています。 今日の常時接続のデジタル世界では、絶え間なく高まる顧客の要求のために企業はプレッシャーにさらされていて、ITサービス担当者はデジタルサービスを健全かつ継続的に運営するために努力していますーしばしば個人の健康と生活が脅かされるほどに。仕事の呼び出しに応答するため、真夜中に携帯電話が鳴る音に起こされたり、人生の重要なマイルストーン（子供の初めての学校演劇のような）を逃したことなど想像してみてください。燃え尽きてすぐにワークライフバランスのいい仕事が欲しいと考えたことがあるでしょうか？

それでも、私たちは、米国、英国、オーストラリアの800人以上のITプロフェッショナルを対象に実施した最近の調査による３つの発見に驚いています それは、

家族生活はITマネージャーの想像以上に荒れている 認知度の欠如はITOpsの職業病となっている ビジネスにかかるコストは、労働力の喪失だけでなく苦労している従業員の生産性低下にも及ぶ

ということでした。

PagerDutyが依頼した調査レポートでは、常時接続のデジタルサービスを管理する責任が家庭生活に影響を与えているとの回答が94％となっています。さらに、半数以上（51.3％）が、デジタルサービスの中断や停電に対処するために、1週間に10回以上睡眠や個人的な生活の中断を経験したと指摘しています。

コンスタントに起こる呼び出しがオンコール担当者の健康や個人生活に悪影響を及ぼしているという統計にもかかわらず、調査回答者の約4分の3（72％）が、彼らのマネージャーはt担当者が厳しいオンコール時間を過ごしていることをを全然知っていないという結果になりました。それに対して、 調査のITマネージャーの58.9％は、彼らのチームが厳しいオンコール時間を過ごしていることをほとんど知らなかったと答えています。

悪い業務管理はデジタルトランスフォーメーションを妨げる可能性がある

IT管​​理者と企業全体は懸念すべきです。なぜか？

Forresterによると、多くの企業ではクリティカルな役割を担うタレントの不足がデジタルトランスフォーメーションを妨げることにつながっています。このようなタレントの欠如は、悪い業務管理と結びついた場合に、最終的に損益に悪影響を及ぼし、従業員の離職率や売上に直接悪影響を与えます。

健全なITエコシステムを維持するためにオンコール担当者はいつでも準備を整えていることを要求されます。その結果、燃え尽きたり、離職したりする不幸な従業員が生まれる可能性があります。しかし、ITOpsの始まり以来、運用上の管理は、人ではなくサーバやアプリケーションに集中しており、それはしばしばビジネスに損害を与えるものでした。

しかし、サーバやアプリだけでなく、人の面から業務の健全性を見ると、なぜIT管理者はオンコール担当者の健康状態をより詳細に把握する必要があるのかが分かるようになります。一部の回答者（23.1％）は、仕事と生活のバランスがとれない結果、新しい仕事に移る可能性が高いと答えています。さらに、組織が業務の健全性を改善するための対策を講じないと、残る人の生産性も低下する可能性が高くなります。 事実、94.5％の回答者は、継続的な中断が作業生産性にも影響を及ぼすと回答しました。

データの利用によりチームの健康を変える

いま指摘したように、良い人材を失うことは、組織がデジタルサービスをどれだけうまく提供できるかに悪影響を及ぼします。では、従業員の健康と幸福をどのように改善できるでしょうか。

それを知っているかどうかに関係なく、あなたはすでに現在の操作の健康状態を把握するためのデータを持っています。そのデータのロックを解除するだけで、改善すべき点を判断することができます。

PagerDutyは、この課題を認識してOperations Health Serviceを開発しました。これは機械学習、データサイエンス、専門サービス、1万を超える組織のピアベンチマークデータを組み合わせて、IT管理者が社員の健康状態を見て自社のデジタルオペレーションを評価できるようにするものです。

今日からPagerDutyがいかに組織のデジタルオペレーションをに人間的にすることができるかを学び、業務の健全性を向上させてください。

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらです。

「Postmortem Guide」を発表したとき、私は責任を問わない事後検証を行うことの価値と、継続的改善の文化を確立する方法について書きました。このシリーズの最後である事後検証の本記事では、効果的な事後検証ミーティングを開催する方法について説明します。*

私が参加した最後の事後検証ミーティングでは、システムで何が起きたのか、どのように対応したのか、問題が二度と起こらないようにするためにどのような改善を加えるべきかを話し合いました。PagerDutyには責任を問わないという文化があるので、誰かを名指しで非難したり、感情を傷つけたりはしませんでした。しかし、継続的な改善をという点において、この会議時間を最も効果的に活用しているのかどうか疑問に思いました。

インシデントを最適に分析する方法については、多くの記事が書かれています。「事後分析をする」というと、とかく分析のプロセスと結果として得られるドキュメントの形式に焦点が当たる傾向があります。多くの場合、このプロセスは、分析の結果について話し合うための事後検証ミーティングで終わります。私たちは最近、なぜ事後検証が重要なのか、そしてどのように実践するべきかについての詳細な情報をコミュニティに提供するため、総合的なPostmortem Guideを始めました。しかし、このガイドのために研究を行っているとき、私は事後検証ミーティングそのものについてはほとんど書かれていないことに気づきました。

分析を実行し、事後検証のドキュメントを完成させることは、インシデントから学ぶための重要な最初のステップです。結果を議論するために会議をフォローアップすることで、チームは分析からさらに多くの価値を引き出すことができます。事後検証ミーティングの目的は、インシデントの原因に対する理解を深め、実際に行動を起こせるようにアクション項目に賛同を得ることです。

一緒に、そしてクールに

何が起こったのかについてのライブ会話をするために（物理的またはバーチャルに）部屋に集まると、分析は新しい方向に進み、すべての人にとって学習ポイントが深まります。 最も重要なのは、議論することで、同じ問題が再発するのを防ぐのに必要なアクションの優先順位にチームの賛同を得ることです。

これは、「言うは易く行うは難し」です。 事後分析をみんなで読むだけでは、この会議から最大の価値を引き出すことができません。感情が高まり会議の進行が困難になることもあります。チームが責任を問わない事後検証を実行するために最善を尽くしたとしても、彼らが犯したした失敗について議論するとき、人々はどうしても防御的になるでしょう。

私は元スクラムマスターとして、事後検証ミーティングと振り返り（retrospective）の類似点に気づきました。振り返りミーティングでは、チームは最後の反復がどのように行われたか、またどのように改善したいかを検討します。同様に、事後検証は過去のインシデントの考察とそこから学びを得るために行われます。チームが奮闘していると、ふりかえりミーティングは個人間の摩擦と感情的な反応を引き起こします。事後検証も恐れや怒りといった感情を伴うことがあります。

進行役を担う

PagerDutyでの事後検証ミーティングとふりかえりの運営方法には大きな違いが1つあります。ふりかえりはチームのアジャイルコーチによって進行されますが、事後検証ミーティングは通常Incident CommanderまたはPostmortem Ownerが主導します。

これら2つの会議の類似点を考慮すると、事後検証ミーティングも熟練した進行役の参加が重要であることに気付きました。会議における進行役の役割は、他の参加者とは異なります。彼らは彼ら自身の考えを表明するのではなく、議論を軌道に乗せ続け、メンバーに発言するよう促します。対応者が会議の進行役をやると、グループ全体の一体感を保ちながら彼らの経験やアイデアを共有することは困難であると学びました。

指名された進行役は、グループが会議の2つの主たる目標に集中するのを手助けします。

インシデントにつながった原因についての理解を深めること 事後検証で明らかになったアクション項目への同意を得ること

チームが議論をしている間、進行役は全員が快適で誰か1人がミーティングを支配しないよう、グループダイナミクスに注意します。進行役がこれをどの程度きちんと実行しているか注目しましょう。

インシデントの原因を探る

進行役が直面する議論を妨げる2つの大きな課題があります。

システム障害の責任を個人に負わせてしまう傾向がある 分析が深く掘り下げられていない

進行役は非難が起こりそうな時に会話の方向を変えることで、チームが責めを避けるようにすることができます。事後検証の目標は、どのような体系的要因がインシデントを引き起こしたのかを理解し、この種の失敗が再発するのを防ぐ方法を見つけることです。誰がミスを犯したのかではなく、ミスがどのように起きたかに焦点を絞るようにします。

進行役は、分析を妨げ、責任追及を暗示する「誰」や「なぜ」という質問を避け、代わりに「何」や「どのように」という言葉を使って「あなたは何が起こっていたと思いましたか」や「必要な支援をどうのように受けましたか」というような質問をしてください。

特定の対応者を抽象化した人間に置き換えることにより、ある行動についての責任追求を避けます。誰でも同じミスを犯した可能性があることをチームに思い出させてください。「何がその行動をとらせたのか」と尋ねることにより、誰か1人を責めるのではなく、グループ内の誰もがシステム障害の原因についての率直な意見を述べることができるようになります。

たとえあなたが責任追及を極力避けるという文化を持っていたとしても、インシデントにつながった多くの条件を深く理解するのは難しかったりします。進行役の役目は、グループに考えさせるために適切な質問をすることです。単純に「はい」または「いいえ」で答えることができる質問ではなく、常に自由回答形式の質問をしてください。会話の初心者は事後検証ガイドの分析用の質問を参照してください。

メンバーの賛同を得る

製品管理者や技術管理者など作業の優先度を決定するチームリーダーに、事後検証ミーティングへの参加を奨励するために、カスタマーエクスペリエンスに対する脅威と技術投資へのニーズについての見識が上がることを説明します。事後検証ミーティングは、行われるか、あるいは行われない作業に関する困難な決定と、それらの選択の予想される影響について話し合う機会です。

下手なチームダイナミクスは全員の積極的参加を妨げる可能性があります。進行役はこれらのパターンに注目してグループを導きます。1人が会議を支配している場合は、その人が言っていることを繰り返し（例：「◯◯ですね。それは分かりました」）、続けて「別の観点があれば聞きたいのですが」と他の人が話すのを促します。

誰かが人の発言を遮っていたら「初めの人の言ったことが聞こえませんでした」または「ちょっと待って。マリーさんの意見を最後まで聞かせて 」と言いましょう。

反対に、意見を話す人がいないときには「他に何か検討することがあるでしょうか？」と尋ねれば参加を促せます。

これらの会話のトリックにより、進行役は全員を参加させることができます。そして最も重要なのは、アクションプランへの合意に向かって会話を進めることです。たとえ最善の行動方針について意見の相違があったとしても、みんなが聞いたことがあると思えば、グループをアクションプランに参加させることができます。

成功のために進行役を配する

チームの議論をフォローして、あなたの事後検証分析を最大限に活用してください。ライブで会話をすることは、全員の学習を深め、新たな洞察につながる可能性があります。ただし、単にその会議をスケジュールして文書を一緒に読むだけでは不十分です。事後検証ミーティングを成功させるためには、熟練した進行役の助けを借りてください。

その他の円滑化のヒントと効果的な事後検証の実行方法については、「 Postmortem Guide」を参照してください。PagerDutyのフォーラムでは事後検証ミーティングからどのようにして最大の価値を得るかについてご意見を募集しています。

本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

「インシデント管理」と聞くと、ITプロフェッショナルがバックエンドシステムを管理していると考えるかもしれません。おそらくカスタマーサポートチームは自分たちとは関係ないと考えていることでしょう。

ですが実際のところ、カスタマーサポートチームもインシデント管理から多くの利益を得ることができるのです。

顧客を幸せにする

ほとんどすべてのIT専門職は、カスタマーサポートに回ってくるようなことがらは一般的に良くないことだと考えているでしょう。私たちは顧客に技術サポートに頼るような経験をさせたくはありません。カスタマーサポートを提供することに直接的なコストが伴うだけでなく、こういった経験をした顧客は将来的に顧客でなくなる可能性が高まるからです。

結論は、顧客を満足させることが重要であるということです。満足した顧客は、あなたの会社との経験を何人かの友人に伝えてくれるかもしれません。怒っている顧客は、自分のTwitterフォロワーに体験をシェアしたり、中には消費者庁に駆け込むようなこともあるかもしれません。

では、カスタマーサポートとインシデント管理はどんな関係があるでしょうか。その性質上、カスタマーサポートは受け身の機能です。通常、顧客は問題に突き当たるとテクニカルサポートに電話を掛け、テクニカルサポート部門は顧客の苦情に対応することになります。インシデント管理も同様に受け身なものですが、予防的な対応も可能です。適切な監視ソリューションを使用することで小さな問題を解決して、チームをより大きな問題の解決に向かわせることができます。これにより、サポートコールが少なくなり、顧客満足度の向上にダイレクトにつながります。

積極的なインシデント管理を通じてサポートコールを削減するという考えは魅力的ですが、インシデント管理計画が適切に実装されている場合にのみ有効です。重大ではなかったり重複している警告は抑止し、より緊急な問題のアラートを発信することで、ソフトウェアはIT担当者の大きな助けになります。しかし、最終的には、インシデント管理プログラムの成功は、問題が発生したときに決定的な行動をとるITスタッフの能力に左右されます。

担当者を呼び出せることの重要性

インシデントが迅速に解決されるようにするためのひとつの方法は、発生する可能性のある問題をITスタッフが常に処理できることを確認することです。組織に24時間対応のITスタッフがいない場合は、呼び出し可能なサポートチームを持つ必要があります。これは全員が常にオンコールでなければならないというわけではありません。輪番制のコール対応スケジュールを組めば、ITチームの誰かが常に起こりうる様々なインシデントに対応可能になります。

時間外の緊急事態に対処するためにコール対応スタッフを用意しておくという考えは新しいものではありません。熟練のIT技術者であれば、たいていは週末や非常識な時間に呼び出された経験が一度や二度はあると思います。

ほとんどのITサービスは時間外の問題に対処するために誰かを呼び出すことを躊躇しないものですが、関係するすべての人がより無理なく日常生活を送れるようにするためには、いくつかのポイントがあります。

オンコールオペレーションのベストプラクティス

まず、時間外のインシデントでITスタッフにアラートを出すのは、インシデント管理ソフトウェアによって起動される自動プロセスでなければなりません。自動アラートを使用することで、IT担当者は問題を可能な限り迅速に認識することができます。自動プロセスをとっていないと、誰かがインシデントを発見してIT部門に電話をかけてくるまで、ITスタッフはその問題を認識できない可能性があります。その頃には、顧客の側でも問題を経験し始めているかもしれません。

これは別のポイントをもたらします。よほど小さな組織でない限り、1人のオンコール担当ではなく、オンコールチームを用意するのが一般的です。ITは複雑な分野であり、チームの誰もが組織全体で使用されているあらゆるテクノロジーの専門家であることを期待するのは非現実的です。オンコールチームを組織しておくことで、インシデントが発生した場合、問題を解決するために相互補完的なスキルセットを持つ人々のグループを確保することができます。これは、オンコール技術者が何らかの問題が発生したときに、解決に必要なスキルを持つ特定の人を探すより好ましい方法です。輪番制のコールスケジュールは、ある人に常に役割を負わせるのではなく、いつでも問題に対処できるチームが存在することを保証します。

業務時間外に待機するのは決して楽しいことではありませんが、24時間体制で顧客にサービスを提供する企業では、ITの専門知識を年中利用できるようにすることが非常に重要です。顧客は企業の最も貴重な資産であり、企業のブランドは顧客に依存しています。インシデント管理ソリューションを活用する積極的なカスタマーサポートチームは、問題が顧客に悪影響を与えるのを防ぐことができ、より高い顧客満足度につながります。

小さな目でスパイして

「誰がリンクをクリックしたかを追跡する機能を構築したい」

そのメールをセールスチームに送ったとき、私は気味の悪いストーカーと思われたようだ。なぜクリックされた地球上のすべてのリンクを追跡したいのだろうか？ 私は私についての厄介な噂を払拭するために、どんな状況だったのか知る必要があると判断した。そして、セールスチームのメンバーが警戒してセキュリティチームに報告したため、実際にフィッシング攻撃という脅威が検出された。

私の考えを説明するフォローアップメッセージを書いたとき、私はカーテンを剥がして「セキュリティのしくみ」を明らかにすれば会社全体が利益を得ることができると気づいた。拡大と混乱の期は熟した。セキュリティインシデント対応者のニーズを理解すれば、PagerDutyを使用して顧客が新しい問題を解決する助けになれると。

セキュリティインシデント対応の仕組み

セキュリティチームには、ビジネスに対するサイバーセキュリティリスクを軽減し、顧客の信頼を向上させるという2つの主な目的がある。私たちが毎日直面している本当のリスクは、攻撃者がいつでも任意のコンピュータ上でマルウェアを実行できることだ。セキュリティインシデント対応チームは、私たちが直面している脅威の影響を理解し軽減するプロセスを経験している。ここでPagerDutyで行う高度な手順は、 NISTのサイバーセキュリティフレームワークに基づいており、以下のようなセキュリティインシデント対応計画からなっている。

検出

封じ込め

対応

回復

さて、PagerDutyセキュリティチームがこのような脅威にどのように対応しているかを見てみよう。

急ぎの質問としては、

悪質なマルウェアが含まれているか？

悪質なマルウェアはどこででも発現したか？

この2つの質問に答えることで、攻撃の最初の影響を理解し、被害を封じ込めることができる。

最初の質問への答えは、同僚からの攻撃のレポートを受け取ったときにすぐに分かった。私たちの手元にはリンクが付いた電子メールがあり、リンク先がマルウェアかどうかを確認することができた。そのような場合、安全のため隔離されたコンピュータの中の仮想マシンを使用してリンクをたどって疑わしいファイルを検査する。こうすれば、リンクが何か悪質なものをダウンロードした場合は、直ちに仮想マシンを止めることができるため、マルウェアは損害を与えられない。

この方法を使用すると、リンクがマルウェアをインストールしたことが検出された場合、そのリンクをブロックして、オフィスネットワーク上の誰もそれをダウンロードできないようにできる。しかし、ブロックを設置する前に誰かがすでにダウンロードしていたらどうだろうか？

これは2番目の質問につながる。悪質なマルウェアはどこででも発現したか？ この質問に答えるには、誰かがマルウェアをダウンロードしたかどうかを調べる必要がある。誰がリンクをクリックしたのか？ マルウェアをダウンロードした人が複数いる場合は、すぐにネットワークからコンピュータを切り離して、マルウェアが他のシステムと通信できないようにする必要がある。マルウェアはネットワーク上の他のコンピュータを攻撃し、コンピュータからデータを盗み、インターネット経由で攻撃者に送信する可能性がある。これらの行動は、それぞれ「lateral movement」（横への動き）と「exfiltration」（抽出）と呼ばれる。

感染したコンピュータをネットワークから切り離した後、マルウェアが実行可能だったかどうかを確認する。必ず、問題に対応する前に、まず攻撃をカットすること。できるだけ早く感染が広がらないようにする。ひょっとするとあなたは幸運かもしれない。マルウェアはWindowsやMacでのみ実行可能で、それ以外のOSにダウンロードしても実行されないならば、あなたが影響を受けることはない。

では次に、3人のユーザーがリンクをクリックし、悪意のあるソフトウェアが彼らのコンピュータで実行できることが判明したシナリオを見てみよう。これは本当に危険な状況だ。3台のコンピュータがネットワークから切断される前に、マルウェアが実行中に何をしたのか理解する必要がある。インターネット越しにデータを抽出したのだろうか？ 横への動きを使って別のコンピュータを攻撃することができたのだろうか？ パスワードを盗もうとキーロガーをインストールしたのだろうか？ これらの質問に対する答えは、私たちがどのように対応し、攻撃から回復するために何をすべきかを決定する。

残念ながら、現在のところ誰かがリンクをクリックしてマルウェアをダウンロードしたかどうかを即座に特定できる技術はない。私はいつも誰もクリックしていないことを願っているが、それが望めなくともせめてどのシステムも影響を受けていなければ、夜はよく眠れるだろう――だから私は誰がリンクをクリックしたかを追跡したいのだ。

セキュリティのためのPagerDuty

インシデント対応チームがセキュリティイベントが検出されたときに迅速に対応することがいかに重要であるかをご理解いただけただろうか。リスクを減らすことが私たちが仕事をして給料を稼ぐ理由だ。あなたのためにできる私の挑戦は、以下の質問に答えること――セキュリティインシデント対応者は、PagerDutyを使用して対応にかかる時間をどのように短縮できるか？ 彼らは横への動きを介して広がる前に感染を封じ込めることができた場合、どのくらいのリスクを排除することができるのか？ どのくらいのコストを節約できるのか？

セキュリティのためにPagerDutyを！ 以下のセキュリティに関するリソースを確認しよう。

セキュリティの混乱：SecOpsとインシデント管理によるITセキュリティの改革

セキュ開発者：PagerDutyを安全に保つ

シグナルサイエンスはセキュリティ上の異常に素早く対処し、PagerDutyで顧客データを安全に保つ

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

3年前、私は 新興スタートアップだったPagerDutyにエンジニアリングマネージャーとして参加しました。 当社は2013年にシリーズAの資金を受けて超成長モードにあり、あらゆる分野で積極採用を進めていましたが、エンジニアリングチームは当時30人以下でした。急成長企業が直面している構造的課題の解決に、私は大きな魅力を感じました。エンジニアリングが100人のDutonian（注：Star Wars: The Old Republicに登場する）の群に増えつつある今、これまでの変化を振り返り、今後に反映させようと思います。

組織構造の進化は魅力的なプロセスです。それはたくさんの間違い、行き止まり、車輪の再発明みたいなことでいっぱいです。うまくいけば、エンジニアリング組織をカバーする文献はたくさんあります。その多くは、賛否両論の抽象的なリストみたいなもので沸騰しています。また企業が採用したプロセスを自画自賛するようなブログ記事も投稿されています。私は別のアプローチをとって、エンジニアリングチームが構造を進化させる試みを繰り返し、それに伴って起こった誤解や学びのすべてを包括して、そこから歴史的な教訓を得たいと思います。

注：イベントや詳細の一部は、ストーリーを分かりやすくするため省略しています。このブログをブックマークしておくと、新しいコンテンツを見ることができます。

昔はサイロ化した組織でした

2014年初頭のPagerDutyは次のように見えました。

エンジニアリング組織は、サンフランシスコ（SF）とトロントのオフィスに分かれていました。

運用チームは、インフラストラクチャの自動化、セキュリティ、およびパーシステンス（SFのみ）を担当しました。

WebアプリケーションチームはPagerDutyの顧客に

見えるの部分を担当し（SFのみ）、主にRuby on RailsとMySQLで

開発をしていました。

バックエンドサービスグループは、信頼性の高いデータ収集と通知配信を担当し（SFとトロントにチームが分割配置されていました）、主にScalaとCassandraで開発をしていました。

DevOpsには部分的な遵守事項しか明文化されていませんでした：

運用チームは、インフラストラクチャ監視アラートのオンコールを担当し、他のチームは導入したコードのオンコールを担当していました。

エンジニアリングが非常に短期間に少人数からいくつかの分散したチームへと成長する中で、製品開発プロセスは未成熟なままでした。スタンドアップとスプリントを使い表面的には敏捷に動いているように見えていたにもかかわらず、基本的にウォーターフォールモデルを使っていました。リーダーシップは、作業すべきプロジェクトを定義し、個々のエンジニアをそれらのプロジェクトに割り当て、目標とする納期を定義しました。予想通り予定はあまり守れずプロジェクトのスプレッドシートは壊滅的な状態になりついには使われなくなりました。

事態はうまく進むように見えませんでした。プロダクトマネージャーは、開発中に発生する可能性のある疑問を予期して詰め込んだ長い機能設計仕様書を作って新しいプロジェクトを開始しました。プロダクトとエンジニアリングは実際には開発中にはあまりやりとりをしないのに、です。この仕様では、Webアプリケーションとバックエンドサービスチームに提示され、ユーザーチームとバックエンドの側面を個別に担当しました。新しいインフラストラクチャのリクエストは、数週間前に運用チームに提出する必要がありました。

こうした努力の数々をすべて一貫した機能リリースに統合することは悪夢でした。我々は不完全なインフラしかなかったり（またはまったくインフラが用意されていなかったり）、バグ、機能ギャップ（各チームが、きっと他のチームがそれをやっていると思いこんでたのです）、エンジニアと製品の両方のオーナーシップやエンパワーメント、日数不足、組織のサイロ化や不整合がありました。期限通りに出したいという欲が、リスクテイクを減らすことにつながりました。私たちは実装においてより慎重になり、製品の仕様を調整することに嫌気しました。

この部門の構造と開発プロセスの組み合わせは、その年のエンジニアリング内の他のすべての議論の最前線にサイロの話題を押し上げました。 おーい僕らはサイロに落ちているんじゃないの？と。

Webアプリケーションvsバックエンドサービス 2つのグループの間 には緊張がありました。 どちらも他のグループが取り組んでいたことをちゃんと理解しておらず、不満でした。

Ruby vs Scala 上記と似ていますが、特定の言語を中心に多くの「自転車置き場」（注：本当に必要か、どこに作るべきかをきちんと検討せずに作られたものを指す）やアイデンティティを構築していました。

オペレーションvs開発チーム。両方とも開発チームがすべてのサーバープロビジョニングのボトルネックとなっていることに不満を抱いていました。オペレーションは迫りくる締め切りに大きなプレッシャーを経験していました。

サンフランシスコvsトロント。 地理的に2つの場所に分かれたエンジニアの間で、同じ場所にあるエンジニアはまとまり、はっきりとした「彼らと私たち」の雰囲気が生まれました。 両陣営は何かと相手に不満を募らせました。

責任の集合を厳密に定義すればチーム間の機能的な連携に多くの余地を残すことはありませんでした。 私たちは、「ワーキンググループ」という概念を試してみたこともあります。小規模で一時的で多様なチームが責任範囲と日程が明確な横断的なプロジェクトに取り組むことを目的として、既存のチームからメンバーを編成しました。こうした取り組みは、プライマリチームを不安定化させて混乱を招いてしまったので、実験は中止されました。

でもみんなで協力してより高い整合性と予測可能性を顧客に提供することが一番大事なことでした。みんながサイロ化に悩んでいたので、解決しなければならなかったのです。私たちはなんとかやり遂げました。

マトリックス化した組織に

2015年の初めには、物事の状態への不満やアジャイル・メソドロジへの関心の高まりが重大になり、部門別に同様が生じました。特定の製品の方向性に合わせていくつかの新しいチームが結成されました。彼らはScrumプロセスに従い、Webアプリケーションとバックエンドサービスチームのエンジニア、製品所有者、Scrumマスター、UXデザイナーで構成されていました。

前年度の製品進捗状況が理想的ではなかったことを考え、新しいチームは製品提供のために最適化されていました。新しい機能の導入に100％時間を費やすことができるように、メンテナンス作業はバックエンドサービスチームに委任されました。これらはKanbanの方法論を採用し、「ベースチーム」として知られるようになり、プロダクト内のすべてのオンコールの責任を含め、すべてのサービスのオーナーシップを取りました。さらに、製品チームに供給された基本チームは、製品作業の増加に伴い、エンジニアが一方から他方に移行しました。

これらは明らかに大きな変化でした。個々のエンジニアへのチームシャッフルの影響を最小限に抑えるため（また、リモートレポートを処理することをやめるため）、レポート関係には触れませんでした。これはもちろん、皆さんの人生を驚異的に複雑にしました。なぜなら、マトリックス型の組織という二重のレポート構造を持っていたからです！多くのエンジニアは、直属のスーパーバイザーに割り当てられていないチームに所属し、マネージャーは、「人事マネージャー」（人員を管理。他のチームに所属する人も含みます）と「機能マネージャー」になりました（チームを管理。一部のエンジニアは別の人にも報告をしていました）。

良かった点は、古いサイロがほとんど壊されたことです。それが復活することはありませんでした。バックエンドサービスエンジニアと緊密に連携するWebアプリケーションエンジニアは、互いの違いを認識しながら、共通の目標に向かって進むことができました。もっとも、ほとんどのチームは地理的にも分散していたため、2つのオフィスを統合するのを不思議に思っていましたが。

悪いニュースは、新たな問題が発生したことでした。

テクニカルメンテナンスに関係するチームを結集することは非常に困難でした。ベースチームは、長期のロードマップを形成し、すべてのプロダクションサービスの運用上のオーナーシップをとる羽目になりました。

フィーダーモデルが各チームの結束に非常に大きな影響を与えました。チームの構成を何度も変えていくことは、士気にはあまり良いことではないことが分かりました。

二重のレポート構造はとても非効率でした。直接のレポートでは日常的な活動が見えず、人事マネージャーと機能マネージャー間ではコミュニケーションのオーバヘッドが起き、責任に関して混乱がありました。

私たちは、敏捷性よりもむしろアジャイルプロセスを採用しました。Scrumは、過剰な仕様、統合、製品のオーナーの関与を確かに助けました。しかし、ソフトウェア配信に対する当社のアプローチは変わらず、機能リリースは依然として価値があるかどうか怪しいという大きな問題があるものでした。

より多くのチームがオペレーションの人々に多くの負荷をかけました。インフラストラクチャの要求が頻繁になり、新しいサービスごとにオンコールの責任が追加されるため、このアプローチは拡張されませんでした。

すべてのことを考慮すると、私たちはまだ1年前よりずっと良い形になっています。

しかし、まだまだ道のりはまだまだありました。

アジャイル組織

新しい組織体系で1年間生活した後、私たちはかなりの数の学習を蓄積しました。 アジャイルはうまくいっていましたが、十分な作業はしていませんでした。DevOpsはうまくいっていましたが、十分に機能していなかったので、マトリックス管理はそれほど良くありませんでした。

2016年の早い段階で、我々は再び再編した。 「垂直」製品スクラムチームは現在、製品の特定の部分を担当していました。 「水平」チームは、製品やインフラストラクチャの問題を横断する責任があり、ベストプラクティスを設定し、他のチームが速やかに動くことを可能にしました。 プロダクトデリバリーチームは、ロードマップ、要件定義、実装、デプロイメント、運用中のコードとインフラストラクチャ（！）の保守を所有していました。 私たちは真の開発者を採用しました.Ops「あなたはそれをコードします、あなたはそれを所有しています」アプローチ。

これは以前の懸念をどのように解決しましたか？

メンテナンスチームはこれ以上ありません。各チームは製品やインフラストラクチャの一部を所有し、迅速に移行し、革新する権限を与えられました。

フィーダーチームはこれ以上ありません。特定のチームに対して人員が開かれました。

もう二重報告はありません！組織として、遠隔のエンジニアの採用と管理をより快適にしました。物理的な距離がもはや障害ではなくなったので、私たちはマネージャーを点線関係のないチームに割り当てることができました。

私たちは物事を終わらせることに集中しています。 GSD（Get Sh * t Done）のマントラは、チームが実用的で生産的で機敏なデリバリーマシンに成長するために、過剰仕様化とオーバーエンジニアリングのイントロスペクトと遺産を捨てるようにチームに挑戦し、私たちの集団意識に浸透しています。

セルフサービスで成長が可能。オペレーションチームは、あらゆる種類のインフラストラクチャニーズに対応できるように、魅力的なChatOpsツールを提供するなど、製品配信チームに力を与えるために多くの作業を行いました。これはDevOpsを徹底的に採用し、インフラストラクチャのアラートをOpsから、実際のホスト（問題をより速く解決できる人）を持つ関連チームに移動するための鍵でした。

GSDの主題はもう少し詳しく調べる価値があります。練習を通して、私たちは、チームの自律性、発明よりも革新的なアイデア、そして実現する解決策ではなく解決するための問題をビジネスにもたらします。顧客にとって何がベストかを知っているという考えを放棄するのは容易ではありません。実行可能な最小限の製品を提供し、開発サイクル中に即座にフィードバックを取り込み、それを組み込むことに重点を置いたのが、レーザーの焦点でした。迅速に反復し、価値を最大化し、金めっきを最小限に抑え、数ヶ月から数日または数週間の間にプロトタイプを顧客の手に渡す時間を短縮することができました。言い換えれば、「アジャイルプロセスに従う」組織から実際のアジャイル組織に変化しました。

製品納品チームの数が増えるにつれて、興味深い現象が発生しました。いわゆる「部族」（Spotifyのチームモデルに対するハットチップ）、つまり共通の機能や共通の使命でチームのグループが出現しました。これらの取り決めにより、共有された所有権、知識の共有、ロードマップの共有（個々のチームのバックログとは別）、共有されたビジョンなどの利点がもたらされました。部族組織は私たちがまだ実験しているものです。部族との習得についての今後の更新についてお楽しみください。

私たちはこの構造で16ヶ月稼働しています。確かにチームと関連するオーナーシップラインは、会社が急速に成長し続けるにつれて進化します。同時に、正しいことがどのように見えるかを知るために、間違ったことを十分に行ったことは明らかです。

学んだ教訓

私が早期に決定したいくつかの決定と、組織が耐え忍んだ厄介な中間的な状態のいくつかに戻って考えると、私は頭の中で自分自身を叩きつけ、 明らかに優れた終わりの状態。 もちろん、現実は決して簡単ではありません。その決定は当時の国家、優先順位、国民、そして私たちの課題の関数でした。 あなたは自分の挑戦のいくつかを認識しているかもしれません。その場合、あなたは私たちの経験から何かを取り除くことができると願っています。

私がそれを何度もやり直さなければならない場合、これは私が私と一緒に持ってくる学習です。

チーム間の依存関係を最小限に抑えます**。 依存関係は、ブロック、バグ、誤解、悪い気持ちにつながります。 チームが他の人たちを待つことなく提供できるようにすると、生産性が大幅に向上します。

チーム構成の変更を最小限に抑えます**。 ビジネスの現実は、時折、リソースをある場所から別の場所に移す必要があることを指示しています。 チームの士気と生産性に重大な影響を与える可能性があるため、人を動かす前に長く考えてください。

チームの所有権と責任を過度に処罰しないでください**。 ここでの柔軟性は、長期的な勝利につながります。 チームに自分の問題を解決させるよう促し、前の2つの点で問題が少なくなります。

継続的な学習と実験を恐れないでください**。 これはコード、プロセス、組織といったすべてに適用されます。 同じことを何度も何度もやり続けると、1つは良くなりません。

アジャイルプロセスは素晴らしいです。アジャイル・カルチャーが優れています。スタンドアップとスプリントレビューは、自分自身で大きな価値をもたらすわけではありません。実行可能な最小限の製品、迅速なフィードバックループ、およびコラボレーションに焦点を当てることは、文化的な変化を必要としますが、提供される顧客価値を最大化します。

コードの運用上の所有権はチームと一緒に存続する必要があります。システムの信頼性、コード品質、および組織のスケーラビリティのバランスをとるための最良の方法です。

クロスファンクショナル、フルスタックのチームが製品の配送に最適です。これは、上記の依存性の最小化ポイントと非常によく似ています。各チームは、外部の専門家やプロジェクトのハンドオーバーを必要とせずに、要件の収集から展開に移行できる必要があります。スペシャリストチームには場所がありますが、以前に議論された「水平」チームの領域ではより多くのものがあります。

どのような環境でも動作できるジェネラリストを雇う。チームメイトは、技術と技術の方向性が変わるにつれて、特定のツール、フレームワーク、スタックにアイデンティティーの感覚を付けてはなりません。成長の著しい環境で成功するために最適な人材は、仕事に適したツールを学習して使用することに重点を置いています。したがって、学習と成長の機会を提供する準備ができていること。

あなたがそれを助けることができるならば、行列での管理を避けてください。 二重報告が解決するように見えるかもしれない問題に対処する他の方法があるかどうかを検討してください。

分散チームを受け入れる。 離れたメンバーと緊密なチームを構築することには課題はありませんが、そのメリットは多くあります。 Martin Fowler氏は、「チームを遠隔地にすることで、チームにもたらすことのできる人の範囲を広げることができます。 遠隔地のチームは、同一のチームが同じ場所にいる場合に比べて生産性が低いかもしれませんが、あなたが形成できる最高の共同チームよりも生産性が高いかもしれません。 、より強固なチーム全体を構築することができます。

組織が成長し成熟するにつれて、減速し、石灰化し、より保守的になる傾向があります。 継続的な改善を実践し、プラクティスを進化させることで、我々は負に陥らないようにし、時間をかけてより機敏で、実用的で、生産的に成長することができました。

3年間（そして多くの）の学習の成果がここにあります！

事後検証（ポストモーテム）シリーズのパート2では、リーダーシップを発揮することから文化面での変化を起こすことまで、継続的な学習の文化を確立する方法を掘り下げます。*

文化は私たちが物事を一つにする方法です。それは一貫した形で目標を満たす幸せで健康的なチームを作るための秘密のソースです。組織の中で定義し、育て、変革するのは最も難しいことです。真の文化的変化には、ポリシーを作って伝えること以上のことが必要です。コラボレーション、永続性、そして実験が必要です。

PagerDutyの私たちはアジャイルの方法論とDevOpsプラクティスの大ファンです。私たちは、ソフトウェア開発から文化の変化まで、継続的な改善の原則を適用しました。反復的な評価とコラボレーションを通じて、文化を正しい方向にシフトさせることができます。

これは別のコアなDevOpsプラクティスである事後検証に思い至らせます。事後検証の成功は単なるプロセスにかかっているのではなく、誠実さ、学び、説明責任の文化に基づいています。企業文化の変革には経営陣の参加が必要ですが、自分の役割に関係なく文化の変革を先導することができます。

身近なところから始めよう

あなたの会社のプロセスの全面的な見直しに着手する前に、どこから始めるのかを把握することは重要です。インシデント後の報告には事後検証プロセスを使用していますか？ あなたが従うステップは何ですか？ 誰が関与していますか？ 失敗についての会話は通常どのように行われますか？ あなたのチームがこれらの議論をすれば、関係者の責任を問わない事後検証を実施する文化への移行を始められると思います。

多くの企業は、重大インシデントの後に、何が起こったのかを検討する会議を開くでしょう。これらの議論の過程で少数の個人がインシデントに対する責任を負わされるのを見ることになるかもしれません。一般的に、全員がもう少し詳しく知る前に、将来問題を避けるための計画を立ててしまいます。さらに重要なことに、少数の人々があなたが避けたいと思う、かなり不愉快な気分で立ち去ります。

あなたのチームに迅速な監査ができるように事後検証の実施のためのステップバイステップガイドを見てください。現在していることや、現在何をしているけれど微調整する必要があるかもしれないこと、そしてしていないことは何でしょう？

責任を問わないことをリーダーに求める

事後検証を組織にまったく新しいやり方として紹介するにせよ、既存のプロセスを改善するために動いているにせよ、文化の変革は難しいものです。伝統的には変革より管理が優先されると思います、しかしボトムアップでの変革は通常もっと成功をもたらすものです。 あなたの役割が何であれ、新しいプロセスを導入するための最初のステップは、経営陣からの承認を得ることです。

変革について思慮深い推論を用いリーダーに近づくことが、その変革が持つはずの重要性と影響を強化するのを助けます。 そのための対話で重要な点は次のとおりです。

責任追及がどれほど有害であるかを明確にし、定量化し、そして責任追及のビジネス上の価値を説明する。

問題を「引き起こした」ことを理由に個人を罰する慣習は、問題が発生したときに人々が責任追及されることを恐れて発言しなくなるように仕向けます。結果としてインシデントを認識して解決するまでの平均時間が長くなり、最終的にはインシデントの影響が大きくなり、深刻な影響を受ける可能性があります。問題が発生したらできるだけ早く解決できるように、リーダーは人々に発言を求めてください。

組織は責任追及される恐れを排除し、共同学習および反復的な設計の改善を促すことによって、システムの回復力を急速に向上させ、イノベーションのスピードを上げることができます。

さらに、バカみたいに聞こえるかもしれませんが、新しい事後検証プロセスを売りこむときに、管理側のせいにしないことを忘れないでください。リーダーがチームに加わっていることを確認してください。インシデント後に誤って責任追及を示唆した場合には、彼らがそのフィードバックを受け取るのを納得するというリーダーシップの確約を得ることが重要です。

ゴールは、継続的改善の文化を作るためにリーダーに確実に参加してもらうことです。

Pro tip___：責任追及をしないという概念を会社の価値にマップできるかどうかを確認してください。例えばPagerDutyの文化的価値観の1つは、特に中断と継続的な改善を受け入れ、常に学習に集中することです。このような責任を問わない事後検証の概念は、これらの価値を支えることに直接対応できます。

チームを指導する

これでリーダーシップが完成しました。組織で大きな文化の変革を遂げることができました。次のステップはあなたのチームの個々のコントリビューターの参加を確保することです。彼らがまだ、インシデントの責任を追及されることを恐れているかもしれないことに留意してください。その恐れは、ポリシーだけでは消えないでしょう。インシデント対応後にどんな方法でも誰も罰せられることはない、という経営陣からのコミットメントを得ていることを必ず共有してください。責任をもっと意識して、責任が認められたらお互いに声をかけて協力することで、同僚との信頼関係を築きましょう。

（グループ内での心理的安全性の重要性について読んでください。）

変革を繰り返す

文化の変革は一晩では起こりません。実験を成功させた結果を新しいプラクティスと共有し、次にそれらのプラクティスをチーム間でゆっくりと拡張するなど、小規模から始めて新しいプラクティスを組織に繰り返し導入します。

始め方：

チームを1人選び、完璧な事後検証の実験を始めましょう。** 始めるには、「事後検証記録の書き方」ガイドを使用してヒントを共有してください。スキルを磨き、他の人に教えます。

小さなインシデントから始めましょう。** 小さなインシデントのビジネスへの影響は小さいため、インシデントの原因として個人をスケープゴートにする圧力は少なくなります。

責任追及する人を批判しないでください**。上記で推奨されているように、個人に責任を負わせがちな人を探してください。必ず声をかけて、チームがこのインシデントに対して新しい、責任追及のないアプローチを使用することを決定したことを伝えてください。

覚えておいてください：責任追及のない事後検証へのグループの信頼を築くために最初は単純なものから始めてください。チームにとって最適なものを試し、次のラウンドで繰り返します。

共有することはケアすること

組織のためでも、単一のチームのためであっても、文化的シフトを促すには大きなエネルギーを必要とします。試みられ、テストされ、そして最終的に採用される前に、それが「難しい」という単なる認識のために、変革は時に強く非難されることがあります。

インシデントレポートを共有することは、最初は直感に反するように思われるかもしれません。成功というより失敗のストーリーを共有するように思えますからね。でもそれとは全く反対に、チームは失敗から学んでシステムを改善し、失敗の発生率を減らせます。

インシデントを個人的な失敗としてではなく、具体的な改善をもたらす学習機会として再考することです。それは士気を高め、ひいては従業員の定着率と生産性を高めます。

批判しないことがアカウンタビリティを育てる

自由に情報を共有し、透明性を促すことで、説明責任を養う環境を支えられます。事後検証のあとに起きることは、システムの健全性にとって重要です。事後検証の行動項目が網羅されたと思われた時点でSLAを設定することは、チームがタスクを迅速に割り当て、優先順位を付けるのに役立ちます。また、許可を待たずにチームが行動に移れるようにします。

Pro-tip*：このSLAをすべてのエンジニアリング部門に伝達し、将来の参考にするために必ず文書化してください。

PagerDutyでは、Sev-1インシデントの再発防止に必要な優先順位の高いアクションアイテム（行動項目）は、インシデントから15日以内に完了することを期待しています。Sev-2インシデントから得たアクションアイテムは30日以内に対処されるべきです。

カルチャーのチャンピオンになる

あなたの会社の文化を良い方向に変えることは、実現が最も難しい仕事のひとつです。信じられないほど微妙で、高レベルの共感を必要とし、そして感情的に疲れることです。継続的に学習する、責任を問わない文化を促進することは、より幸せなチームとより良いソフトウェアにつながるので、組織にとって最も重要でやりがいのある作業でもあります。

評価、コラボレーション、コミュニケーション、そして実証という具体的なステップを適用すれば組織を正しい方向に変えることができます。

現在の事後検証プロセスの状況を知ることから始めましょう

リーダーとチームの了承を得て、責任を問わない事後検証を試しましょう

1チームまたは小規模なインシデントで試してみてください

実証結果を共有して、変化を広めてください

責任を問わない事後検証を採用する方法の詳細については、包括的な「Postmortem Guide」をご覧ください。あなたがどのようにして文化の変化にアプローチし、誠実さを広めているかをお聞きしたいです。当社のフォーラムにアクセスしてコミュニティと情報共有してください

本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

良くも悪くも、私たちの社会はは効率化に取りつかれています。オンラインバンキングやEコマースアプリからスマートIoTデバイスに至るまで、私たちの生活の隅々にその痕跡があります。しかし、私たちは個人生活のほぼすべての面で自動化を使用しているにもかかわらず、PagerDutyとDimensional Researchが実施した共同研究では、90%の企業が問題解決のための自動化をほとんど、あるいは全く行っていないことがわかりました。なぜでしょうか。私たちは簡単なことをより簡単にするため、私たちの生活の中で毎日自動化を利用しているのに、なぜ仕事でもそれを利用していないのでしょうか。

頑張らずに賢く働く

社内では「技術の達人」と呼ばれているにもかかわらず、仕事を終わらせるために面倒な手動のプロセスに頼っているIT担当者の多さに驚くことでしょう。

多くのITチームは、時間やリソースを最大限に活用できていません。その代わりに、問題への対応方法を決定するためにハンドブックに目を通したり、過去のインシデントを手作業で調べて関連性があるかどうかを確認したりしています。しかし、チームの効率を向上させ、収益を守るための最も簡単な方法の1つは、インテリジェントな対応と自動化であり、繰り返し可能な手順を自動化することで、貴重なリソースを他の場所に再配分することができます。

2020年春に発表された最新の機能強化では、インテリジェント対応と自動化に3つの方法でアプローチしています。（1）人とプロセスの調整、（2）対応チームが必要なときに適切なコンテキストと情報を提供する、（3）使いやすい自動化機能を提供することで、問題を迅速に診断して解決できるようにする。これがどのように機能するかを詳しく見てみましょう。

新機能の詳細 インテリジェントトリアージ

PagerDutyイベントインテリジェンスの一部として、モバイルで利用できるようになったインテリジェントトリアージは、チーム作業の重複を防ぐことができます。これにより、複数のチームに影響を与えるインシデントについて、何が本当の原因となっているかを判別するために、Related Insidents機能を使用することができます。Related Insidentsは、イベントインテリジェンスの機械学習機能をノイズ削減の域を超えて拡張し、サービス全体にわたってリアルタイムのコンテキストに基づいた洞察を対応者に提供します。

目下のインシデントに関連している可能性のある他のサービスで同時発生しているインシデントを調査することで、対応者は影響の幅と範囲をより深く理解し、重複したコミュニケーションを回避し、問題解決のためにチームがお互いを邪魔しないようにすることができます。インテリジェントトリアージは、機械学習を利用して以下のことを可能にします。

ビジネス全体で今現在何が起こっているかを見る 問題がローカルなものなのか、他に影響を与えるものなのかを理解する 適切なチームメイトを募り、協力して問題を解決する MTTRの改善

インシデントの再開

時には、インシデントが実際には解決されていないにもかかわらず、対応中に誤ってインシデントをクローズしてしまうことがあります。あるいは、インシデントが終了したと思って大規模なインシデントを解決済みにしたにもかかわらず、その後すぐにモニタリングやカスタマーサポートなどの他のチャネルを通じて、同じ原因に起因する進行中の症状に気づくこともあります。

大丈夫です、間違いは起こります。私たちは皆人間です。だからこそ、PagerDuty は新しいアラートをトリガーすることなく、応答者がインシデントを再開することができる新機能（アーリーアクセス可能）をリリースしました。このシンプルでありながら重要なアクションは、対応者の柔軟性を高め、インシデントの重複を減らし、重大なインシデントの症状が再発していることが判明した場合に、対応チームの再動員をより速く、より簡単にします。また、ServiceNowのような隣接するツールを同時再開することができます。

ランブックオートメーションのインテグレーション

もう1つの方法は、運用上の「ランブック」で取得した手動または部分的に自動化された手順をすべて自動化して、自動化されたインテリジェントなインシデント対応プロセスに接続することです。Amazon EventBridgeとの既存のインテグレーションに加え、ランブック自動化のために新しくリリースされたRundeck、Ayehu、およびPliantとのインテグレーションは、Amazon EventBridgeとの既存のインテグレーションに加えて、手動のITレスポンスプレイワークフローを自動化し、対応チーム内のコミュニケーションと解決スピードを向上させることができます。

Rundeck 統合のランブック自動化機能を使ったインシデント対応の例を見てみましょう。

「Eコマースビジネスのピーク時にサーバがダウンして、顧客がチェックアウトしたり、カートの中の商品を購入したりすることができなくなりました。PagerDutyはインシデントが発生したことを適切な人に警告しました」

さて、どうしますか。どのようにして対応者がインシデントを診断し、解決するための迅速な行動を取ることができるでしょうか。もし彼らが同僚や他のチームにエスカレーションしなければならない場合、あなたは時間をロスすることになります。wikiを閲覧したり、マニュアルのランブックを調べたりする場合も時間の無駄になります。

そうではなく、対応者が行動を起こすために必要な自動化されたオペレーション手順に安全にセルフサービスでアクセスできるようにしましょう。Rundeckによるランブックの自動化により、対応者の誰もが専門家と同じように診断や修理の手順を安全に実行できるようになり、インシデント時間をより短くし、より少ないエスカレーションで済むようになります。

RundeckとPagerDutyのインテグレーションにより、以下のことが可能になります。

PagerDutyのインシデントの開始時に自動的にRundeckジョブをトリガーする。例えば、最初の対応者がPagerDutyにログインする前に診断を開始したり、修理アクションを試したりする PagerDutyのWebやモバイルUIでカスタムアクションを使って、インシデント発生時にRundeckジョブをトリガーする Rundeckジョブが自動的にPagerDutyのインシデントノート／タイムラインを更新する Rundeckジョブが失敗した場合にPagerDutyインシデントをトリガーする

このシナリオでは、ランブックの自動化を利用することで、Eコマースビジネスはリソースをより効率的に展開し、MTTRを改善し、停止の結果として失われる収益を保護することができます。

インテリジェントな対応と自動化を実現

これらの新機能は作業の重複を減らし、機械による手作業の自動化を可能にすることで対応者の負担を軽減します。PagerDutyはチームに少ない労力でより多くのことを行う能力を与えることで、企業の回復力を向上させ、顧客との関係性と獲得した収益を保護することを支援します。

本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

最新のセキュリティ監視：どのツールをスタックに入れておくべきか*

クラウドネイティブまたはコンテナ化されたアプリケーションを管理する際には、セキュリティ監視に関するアプローチを完全に変える必要があります。このような複雑な環境では、従来のツールを使ってセキュリティインシデントを迅速にトラブルシュートし解決するのは無理だからです。

これを念頭においてみると、クラウドベースまたはコンテナ化された環境で効果的なセキュリティ監視を行うのに役立つツールがいくつかあります。

コンテナ監視ツール

イメージスキャンツール：コンテナイメージはDockerのセキュリティの中心です。誰でもアクセスできる公開されたイメージはシステムに脆弱性をもたらす可能性があり、使用する全コンテナイメージを検証することが不可欠です。Docker Hubは、基本的なイメージスキャン機能を提供します。プロセスをより詳細に制御するには、ファイアウォールの背後でも機能するDock（Docker Trusted Registry）を選択することができます。さらに、QuayやGitLab Container Registryのような多くのサードパーティのイメージスキャナがあります。どのイメージスキャニングツールを選択するにしても、スタック内で許可されているイメージの種類を厳重に守ることが重要です。できるだけ公式のリポジトリを選択し、未確認のイメージを使用する必要がある場合は、常に完全にスキャンされていることを確認してください。

エンドツーエンドのコンテナ監視ツール：これらのツールはイメージをスキャンするだけでなく、カーネル、ネットワーク、オーケストレーションツール、アクセスコントロールなど、Dockerスタックのすべてのレイヤーを保護します。Twistlockのようなツールは、全面的にコンテナセキュリティツールと統合し、コンテナの監視を1カ所でできるように​​します。

クラウド監視ツール

Threatstack、Signal Sciences、Evident.ioなどのツールは、Webアプリケーションやクラウド環境全体で侵入検知とセキュリティ監視を強化するソリューションです。これらのツールは、パブリッククラウド環境の急速な変化に対応し、可視性を提供すると同時にコンプライアンス要件を満たすのを助けてくれるのでリスクを軽減するのに役立ちます。

オープンソースの監視ツール

オープンソースの監視ツールは、あらゆる監視スイートの大事な要素です。それらの機能は、クラウドネイティブアプリケーション用に専用に設計されており、活気にあふれた開発者コミュニティが持続しています。

Calicoはコンテナのネットワークセキュリティツールです。ネットワーク全体に1つのファイアウォールを提供するのではなく、Calicoは各インスタンスを1つのファイアウォールで保護します。このようにして、1つのサービスやポッドが侵害された場合でも、他のサービスやポッドは安全に保たれます。Calicoでは、ポリシーを使用してネットワークセキュリティを定義できます。サービスにアクセスするだけで、タスクを完了できるようになり、そのアクセスを取り消すことができます。

ELKスタック（ELKスタックとはElasticsearch社のElasticsearch（解析） + Logstash（収集） + Kibana（可視化）の3つの製品の総称）は、ログ解析ソリューションとして説明の必要はありません。スタックのデータベースコンポーネントであるElasticsearchは、ログデータの分散ストレージと分析を提供します。シャード（注）用の自動フェイルオーバーとクエリの並列処理により、ELKスタックは規模に合わせて構築されます。使用量を増やすと、ELKスタックを維持するのが難しくなるかもしれませんが、ベンダーがスタックのメンテナンスを担当してあなたが自システムのロギングに集中できるように、ELK用のマネージドサービスを選ぶことができます。

（注：DBのインデックスは、単一ノードのハードウェア制限を超える大量のデータを格納しなければならない場合があります。その問題を解決するために、Elasticsearchは、複数の部分にインデックスを分割でき、これをシャードと呼んでます。）

Prometheusは今日最もホットなオープンソースの監視ツールの1つです。これは主にKubernetesとの深い統合によるものです。これは、ポッド、サービス、コンテナ、ノードなどのKubernetesコンポーネントを自動的に検出します。アラートと通知の基本的な管理を行うアラートマネージャが含まれています。高度なアラート管理とレスポンスオーケストレーションのために、PagerDutyのようなプラットフォームと統合されています。

ログ分析ツール

ELKスタックを独自に管理するのは面倒な作業です。特に、ノードの限界に達するとシャーディングがスムーズに行われるようにするのは手間がかかります。この場合、SplunkやSumo Logicのようなクラウドベースのログ解析ソリューションが必要かもしれません。これらのソリューションは、機械学習を活用してログデータから予測に役立つ洞察を収集します。また、他の監視ツールとの統合も容易です。

インシデント管理ツール

スタックが複雑であると、すべてのコンポーネントに関するレポートデータが常に流れ込んできます。これは圧倒的な量になり、ノイズの中の重要なアラートを見落とす原因となります。PagerDutyのようなインシデント管理ソリューションで、他のすべてのセキュリティ監視ツールを補完することが不可欠です。

PagerDutyは、様々な監視ツールと統合し、すべてのメトリックを1カ所に統合します。パワフルな自動化ルールを適用して誤検知を減らし、適切な人に注意が必要なイベントが通知されるようにします。インシデントの最中は、適切な人物を即座にスタックの状況に関与させる必要があります。これがPagerDutyによって実現されます。

ChatOpsツール

火消しに注力している状況では、他の人と協力する必要があります。これまでは電子メールやチケット管理システムを使っていたでしょうが、今日ではSlack、HipChat、Flockなどのコミュニケーションツールがチームコラボレーションを促進します。また、チャットボットがマシンが生成したデータをチャットインターフェースで伝えます。PagerDutyとSlackなどとの統合により、ChatOpsインターフェイスとインシデント管理ソリューション全体でアクションを同期させ、インシデントをより迅速に共同作業し解決することができます。

クラウドネイティブのアプリケーションを保護する際には、DevSecOpsとインシデントのライフサイクルに関する最良のアプローチを採用してください。多くのツールはユニークな機能を提供しますが、選択したツールが他のツールともうまく機能することを確認してください。問題を検出する際に最大の馬力を発揮できるだけでなく、最も重要なときに指先で適切なデータを取得できるようになります。