Category
ベストプラクティス

2018年8月10日  (更新日:2022年6月14日)

成長の機会を与えてくれたPagerDutyでのインターンシップ

私の名前は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社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

続きを読む
ベストプラクティス
2017年9月1日  (更新日:2022年6月13日)

PagerDutyのスケジュール設定をしてみました

ConfigurationからScheduleを選択します。

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

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

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

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

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

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

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

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

続きを読む
ベストプラクティス
2018年3月7日  (更新日:2022年5月19日)

いかにして優秀なエンジニアになるか パート1:レバレッジの向上

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社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

続きを読む
ベストプラクティス
2018年5月28日  (更新日:2022年5月19日)

DNSmetrics:複数のDNSプロバイダから統一したメトリックを集める

マネージド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社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

続きを読む
ベストプラクティス
2018年4月3日  (更新日:2022年5月19日)

チームの健全性に関する驚くべき3つの発見

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

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

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

家族生活は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社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらです。

続きを読む
ベストプラクティス
2019年4月18日  (更新日:2022年4月29日)

Postmortem(事後検証) パート3:事後検証ミーティングを最大限に活用する

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

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

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

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

一緒に、そしてクールに

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

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

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

進行役を担う

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

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

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

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

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

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

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

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

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

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

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

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

メンバーの賛同を得る

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

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

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

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

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

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

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

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

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

続きを読む
ベストプラクティス
2017年12月7日  (更新日:2022年3月11日)     |    ベストプラクティス

カスタマーサポートチームがインシデント管理をどのように活用できるか

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

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

顧客を幸せにする

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

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

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

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

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

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

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

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

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

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

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

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

2018年2月28日  (更新日:2022年3月11日)     |    ベストプラクティス

セキュリティインシデント対応者としての生活

小さな目でスパイして

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

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

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

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

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

検出

封じ込め

対応

回復

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

急ぎの質問としては、

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

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

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

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

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

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

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

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

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

セキュリティのためのPagerDuty

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

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

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

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

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

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

2017年12月30日  (更新日:2022年3月11日)     |    ベストプラクティス

3年間で3倍になった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年間(そして多くの)の学習の成果がここにあります!

2019年4月11日  (更新日:2022年3月11日)     |    ベストプラクティス

Postmortem(事後検証) パート2:学習する文化を取り入れる方法

事後検証(ポストモーテム)シリーズのパート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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2019年5月10日  (更新日:2022年3月10日)     |    ベストプラクティス

Dutonianのような影:シャドーイングでオンコール学習

by Max Timchenko

オンコールシャドーイングをする理由

PagerDutyでは、オンコール中のシャドーイングは欠かせません。 新しいエンジニアにとって、シャドーイング期間は問題診断と解決のストレスや責任を一切伴わずに、より親切でスムーズなオンコール開始の準備として役立ちます。

PagerDutyでシャドーイングを設定するとき、「シャドーユーザー」の行動が実際にオンコール中の主任エンジニアに影響を与えないようにしながら、オンコールのプロセスとアクションをできるだけ正確にシミュレートすることが目標です。これにより、シャドーユーザーは安心し、気楽にしていることができ、主オンコール対応者も邪魔されずに行動することができます。

シャドーイングの使い方

最初のステップは、シャドーイング専用のPagerDutyアカウントを設定することです。 このシャドーアカウントに、シャドーイングをしているチーム用のサービスとeメールインテグレーションを追加します。チームが一度に1人のシャドーイングをしているだけであれば、チームごとに1つのサービスで十分です。同じチームに複数の人がシャドーイングしている場合、それでは済まない可能性があります。

このインテグレーションで使うメールアドレスは、プライマリー(メイン)のPagerDutyアカウントにシャドーユーザーへの通知方法として設定します。これは、チームをシャドーイングするためのプライマリーアカウントのオンコールエスカレーションポリシーに追加されます。

この設定の結果、インシデントが発生したときに、通知が主任オンコールユーザーとプライマリーアカウントのシャドーユーザーに送信されます。これにより、シャドーアカウントに同じ情報を持つ別のインシデントが作成されます。シャドーアカウントはシャドーユーザーに通知します。これは別のインシデントになったため、主任オンコールユーザーが対応しているという実際のインシデントのステータスを変更することなく、必要なこと(受任、スヌーズ、コメントの追加など)を実行できます。

この設定の副次的な利点は、一度設定するとプライマリーアカウントの設定をそのままに、シャドーアカウントを使ってシャドーする人の追加や削除、設定が完全にできることです。もう1つの利点は、週末やオンコールの引き継ぎ日などを除外するようにシャドーイングスケジュールを変更できることです。営業時間中にのみシャドーイングを設定することもできます(シャドーユーザーを本物のオンコールのローテーションに追加しないでください)。

「Dutonian」はStar Wars「The Old Republic」に登場するキャラクター。 「シャドーイング」とは初心者が技術習得のために教師役の行いをそっくり真似すること。

シャドーイングを設定する方法

ステップを詳細に見ていきましょう。手順のいずれかが不明な場合は、以下で使用されている設定手順の多くを順を追って解説する設定と対応者トレーニングのウェビナーをご覧ください。

シャドーアカウントを作成する

PagerDutyアカウントをまだお持ちでない場合は、無料トライアルをお申込みいただければこれを含めた設定が試せます。

プレースホルダーにユーザーを作成する

誰もシャドーイングしていない場合、このユーザーはシャドーアカウントのすべてのシャドースケジュールで使用されます。そして誰も呼び出しません。シャドーイングしている人がいると、対応するスケジュールでテキストボックスのユーザーを上書きします。

スケジュールを作成する

次の3つのエンティティ(スケジュール、エスカレーションポリシー、サービス)がチームごとと、同時に行われているシャドーごとに作成されます。これにより、すべてが整理され分離されます。単一のチームに単一のシャドーを設定している場合は、必要なのは1セットだけです。

この例では、架空の 「Labs」チームを使用しています。 テクストボックスのユーザーをスケジュールに追加し、自分のチームに最適なオンコールスケジュールの作成をします。

エスカレーションポリシーを作成する

新しく作成したスケジュールをエスカレーションポリシーに割り当てます。

サービスを作成する

プライマリーアカウントでシャドーユーザーを作成する

プライマリーアカウントに切り替えて、シャドーアカウントのイベントを生成するシャドーユーザーを作成します。シャドーアカウントに複数のシャドーサービスがある場合でも、チームごとに1人のシャドーユーザーしか設定できません。連絡方法に対応するすべてのシャドーサービスにすぐにメールを生成するように通知ルールを設定します。複数のEメールアドレスを設定することで、1人のユーザーがすべてのシャドーサービスに通知できます。対応するすべてのシャドーサービスにすぐにメールを生成するように通知ルールを設定します。

シャドーユーザーをプライマリーアカウントのエスカレーションポリシーに追加する

プライマリーのPagerDutyアカウントで、「Labs」チームのオンコールエスカレーションポリシーをスケジュールしている可能性があります。 誰がオンコール中かに関係なくシャドーユーザーに通知されるように、そのスケジュールと一緒にシャドーユーザーをエスカレーションポリシーに追加します。

重要:Shadow Userをエスカレーションポリシーに直接追加しないでください。追加すると、この人物の行動が実際のインシデント処理を妨げる可能性があります。

設定のテスト

これで設定は完了です。 実際に動作するかをテストできます。プライマリアカウントでチームが使用しているサービスを選択し、手動でインシデントをトリガーします。

インシデントはプライマリーアカウントに表示されます。

インシデントはシャドーアカウントにも表示され、プレースホルダユーザーが呼び出されます。

シャドーインシデントを受任して解決しても、プライマリーアカウントのインシデントには変更が加えられていないことに注意してください。 これで完璧です。

シャドーイング用のユーザーの設定

シャドーしたい人がいるときは、シャドーアカウントに招待してください。通知方法やその他のユーザー情報を通常どおりに設定するようにユーザーに依頼してから、それをシャドースケジュールに上書き設定します。シャドー期間が終了したら、ユーザーを削除します。

スケジュールメモ

PagerDutyでは、シャドーイングのためのサービスとスケジュールを別々に持つことで、シャドーイング時間を変更できます。週に7日、1日24時間などというプライマリーのスケジュールに従うのではなく、週末を除外したり営業時間のみにしたりすることで、シャドーイングの負担を軽減することができます。

「オンコールシフト時間を制限する」には特定の日を除外するのが最も簡単な方法です。営業時間のみのシャドーイングを設定するのはシャドーサービスで簡単にできます(例:「対応者に通知する方法」および「定義されたサポート時間を使用する」)。

注意:シャドーイングプラクティスを設定する際に、シャドーがオンコールローテーションに追加されると、それはプライマリーのオンコールになります。そしてシャドーがエスカレーションポリシーに追加されると、そのアクションはインシデント処理に影響します。

どのようにしてシャドーを私たちの文化に吹き込むか

PagerDutyのシャドーイングプラクティスは誰でも見ることが出来ます。これは、会社の全員にPagerDutyの機能を知ってもらいたいがためです。社内での立場に関係なく、PagerDutyを使用してエンジニアリングチームのシャドーイングに1週間かけて機能と使用方法を理解させることをお勧めします。週単位のオンコールローテーションを実施しているチームの中には、週末と次の担当者に引き継ぐ日を除いた時間をデフォルトのシャドーイングスケジュールとしているところもあります。これですと、週4日、1日24時間の「シャドーイングシフト」が成立します。

チームのほとんどは、シャドーイングを開始したい時期と、オンコールローテーションに参加する準備ができた時期を新しいエンジニアに決定させます。チームの期待するところは、シャドーイングは最初の3カ月のうちに始まり、責任と失敗を非難しないことを共有する文化は、シャドーイングから本番のオンコールへの移行の垣根を低くします。

PagerDutyのシャドーイングの設定方法が理解できたら、この重要なプラクティスを利用してオンコールの経験を改善し、エンジニアの円滑な参加を促進してください。

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

2020年7月20日  (更新日:2022年3月10日)     |    ベストプラクティス

インテリジェント対応と自動化で、少ない労力で多くのことを行う

良くも悪くも、私たちの社会はは効率化に取りつかれています。オンラインバンキングや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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2017年12月26日  (更新日:2022年3月10日)     |    ベストプラクティス

「インシデントコマンダー」に求められるトップスキルとは―養成のプロセスを考える

組織は、オンコール の負担を下げつつ顧客に高いレベルのサービスを提供するために多くのインシデント対応の司令官( 「インシデントコマンダー」)を必要とします。多くの人は上級の技術者(シニアテクニカルリード)だけがその役を担えると思っているので、インシデントコマンダーになりたがりません。しかし、実際には「ソフトスキル」のほうが重要であり、この記事で説明されているような明確なプロセスで、チームは障害対応を主導し調整を成功させる人員を養成できます。*

私はエンジニアではなく、PagerDutyのスクラムマスター(チームのまとめ役)です。私は最近インシデントコマンダーになりました。インシデントコマンダーとして働くには上級の技術者である必要はないということを最初に学びました。*

インシデントコマンダーには誰でもなれる

効果的なインシデント対応には、インシデントコマンダーが意思決定者として機能し、明確に調整をする必要があります。ユニークなスキルが求められる厳しい職務です。インシデントはいつでも発生するので、オンコールの負荷を軽減し、燃え尽きるのを回避するのに十分な数のインシデントコマンダーが必要です。したがって、インシデントコマンダーを養成するプロセスを開発することが重要です。

インシデントコマンダーにとって、組織のサービスが相互にどのようにやり取りしているかという知識は重要ですが、インシデント対応をリードするために高度な技術を備えている必要はありません。インシデントコマンダーは、技術的な回復や調査作業自体は自分では行わず、キーになるソフトスキルを駆使してインシデント対応をコーディネートするのに注力することが重要です。インシデントコマンダーは、ベストな対策を決めるために、今明らかになっている症状と対策案を積極的に聞き取る必要があります。自分が選ぶアプローチには技術的な知識によるバイアスをかけないようにしなければなりません。

インシデントコマンダーには職位や技術的な専門知識に関係なく、誰でもなれます。PagerDutyのインシデント対応マニュアルは、独自のプロセスを形式化するための素晴らしい出発点ですが、座学だけでは新しいインシデントコマンダーを完璧には訓練できません。適切な訓練には実践的な練習が必要です。PagerDutyでは、主要なインシデント対応を導く上で、ほとんどのジュニアチームのメンバーでも快適にサポートできるトレーニングプログラムを開発しました。

主な教育内容

プロセス**:インシデント対応プロセスは、発生した問題を迅速に解決し、SLAの範囲内でシステムを継続稼働させるのに役立ちます。これは明確な役割とコミュニケーションルールを持つ構造化されたプロセスです。優れたインシデントコマンダーは、プロセスに精通しており、混沌とした状況も整理できます。

指示伝達**:インシデントコマンダーは、指示伝達に慣れていなければなりません。タスクを委せるのがあなたの責任なので、職位に関係なく、何をすべきかを相手に伝えることを恐れてはなりません。

時間管理**:インシデント対応中は、時間設定が重要です。タスクを委任するときには、指示を更新するためにいつチェックするかを相手に伝えます。変化する情報に追随したいなら、オンコール中であっても全員への定期的な指示更新のリズムを維持し続けるべきです。

聴取**:体制と方向性は重要ですが、エキスパートのフィードバックに耳を傾け即断即決で計画を変更することも必要です。オンコールに携わる全員からも情報と提案受けられるようにします。あらゆる提案を聞いて、あなたが最終決定をします。

これらを明文化し、プロセス、指示伝達、時間管理、 および聴取をどのように実践するかを正確に話しましょう

当社のインシデントコマンダーは、インシデント対応に関心のある全従業員に対して、営業時間中、常に問い合わせを受け付けています。訓練開始を決めたインシデントコマンダーのタマゴたちはその間に質問をし、プロセスについて学べます。これは、たくさんのインシデントコマンダーが必要な理由を説明する機会であり、みんなが試しにやってみて学ぶのを助ける機会です。

インシデント対応の準備のためにスタッフを訓練する方法を知りたい場合は、次の無料のウェビナーに登録してください。

Introduction to Being an Incident Commander インシデントコマンダーの紹介(英語)

Introduction to Being an Incident Responder インシデントレスポンダの概要(英語)

私たちは就業時間内にプロセスをキックスタートした後、インシデントコマンダーのシャドウスケジュールに訓練生を送り込みます。インシデントコマンダーのやることをシャドウすることで、訓練生は実際にオンコールをしているような気分を味わえます。また、インシデントコマンダーが呼び出されるたびに、一緒に起こされたり自分の仕事を中断されたりします。訓練生はシャドーイングの間にインシデントのコールに加わります。研修生は、「沈黙の観察者」のままにしておいて、最後まで質問をさせずにおくことが重要です。インシデントコマンダーは、事が終わってから訓練生の質問に答える時間を取って、彼らの学習を助け、満足度を高め、コミュニティにサポートされていると感じられるよう計らいます。

研修生がいくつかのコールを聞いた後は、進行中のインシデントのタイムラインを文書化して、スクライブ(記録者) として手伝うように勧めます。より長いインシデントでは、頻繁な引き継ぎが効果的な対応を維持し、燃え尽きを避けるために大きな違いを生むことがわかっています。記録者として参加することはインシデントコマンダー候補がその準備が整う前に手助けを始めるには非常に良い方法です。このようにインシデント対応に取り組むことで、訓練生はプロセスにさらに精通し、自信を高めるのに役立ちます。

いくつかのインシデントコールを聞いて手助けをした後、訓練生には勇気を出してメインスケジュールに入るように促します。彼らは、バックアップインシデントコマンダーのサポートでコールをリードする、リバースシャドウをすることができます。バックアップが対応の全過程で役に立つということを訓練生に理解させてください。新たなインシデントコマンダーにコールを担当させることが重要で、そうすれば彼らは信頼を得られ、さらに自信を深められます。ヒントやリマインダー、励ましなどを添えて個人としてメッセージを送ってください。

新しいインシデントコマンダーが最初のインシデント対応をうまくリードした後は祝ってあげてください。効果的なインシデント対応を導くことは、お客様のビジネスの成功と顧客の幸福に直接影響し、チームの士気を維持するうえでも重要です。互いをサポートし合うインシデント対応者のコミュニティを作ることで、より多くのインシデントコマンダーを育てることができ、オンコールの負荷を減らせるようになります。

オンデマンドのウェブセミナーを使い、インシデントコマンドとインシデントレスポンダのトレーニングを開始してください。

インシデント・コマンダー・トレーニング:主要インシデント時の対応

Incident Commander Training: Leading the Response During Major Incidents

インシデントレスポンダトレーニング:重大インシデント時の成功のベストプラクティス

Incident Commander Training: Leading the Response During Major Incidents

2017年12月20日  (更新日:2022年3月10日)     |    ベストプラクティス

セキュリティスタックに入れておくべき6つの必須ツール

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

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

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

コンテナ監視ツール

イメージスキャンツール:コンテナイメージは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とインシデントのライフサイクルに関する最良のアプローチを採用してください。多くのツールはユニークな機能を提供しますが、選択したツールが他のツールともうまく機能することを確認してください。問題を検出する際に最大の馬力を発揮できるだけでなく、最も重要なときに指先で適切なデータを取得できるようになります。

2018年4月18日  (更新日:2022年3月10日)     |    ベストプラクティス

「シフトレフト」:オペレーションがセキュリティを早くプロセスに組み込むために

クラウドセキュリティ会社の運用のプロとして、私はオペレーションとセキュリティを同時に実現できるかどうか―理想的な世界においてそうすべき―ということについて独自の視点を持っています。今日のハイテク業界で見られる共通の問題の1つは、開発プロセスにおいてセキュリティの実現がほとんどいつも遅れているということです。

セキュリティというのは完全に別個の規律なので、それをタイトなDevOpsフィードバックループに組み込むことは難しく思えるかもしれません。しかし、それは可能なだけでなく、思ったほど難しくないということをここで伝えたいと思います。そして、それを普通に行えれば、多くの問題を除去しながら全体的なセキュリティ方針に大きな違いをもたらします。

特に、「シフトレフト」というコンセプトは、チームが以前にデプロイプロセスの後半で行っていたセキュリティ導入プロセスを早期に組み込むことを可能にします。この記事では、これを行う方法について説明します。

「遅すぎる」とはどういう意味か

まず、今日DevOpsプロセスにセキュリティがどのようにもたらされているかを見てみましょう。実際は多くの場合そうなってはいません。これは、エンジニアが準備できたコードをデプロイするとき、セキュリティプロセスはまったく含まれていないことを示しています。もちろん、これを行う開発者は自分の仕事をしているだけです。彼らは製品チームから機能をリリースするという圧力を受けています。できるだけ早くコードを書き上げるために、自分がしなければならないことをやっているだけです。

他のケースでは、セキュリティチームが投入され、門番としてコードが外に出る前にセキュリティレビューを行うことがあります。セキュリティ要員が呼ばれて、欠陥があるかどうかを確認することは良いことです。しかし、最後の最後まで待つことは、継続的デリバリーのサイクルを妨げる可能性があり、今日のアジャイルな開発風土では選択肢とはなりえません。言うまでもなく、それはお互いを対立する立場に立たせることになり、チーム間の緊張につながる可能性があります。

いかにして「シフトレフト」するか

ここ数年、DevOpsチームをよりスピードアップし、継続的デリバリーで開発するよう最適化している組織がますます増えています。しかし、今はセキュリティを織り込む時です。それが「シフトレフト」です。

今までは、

Devチームが開発を行う → テスト → セキュリティチームがチェック(やらないこともしばしば) → デプロイ

というプロセスだったのを、

Devチームが開発を行う → セキュリティチームがチェック → テスト → デプロイ

というように、セキュリティを確保するプロセスを前段階に組み込むのです。それを実現するためのいくつかのヒントがあります。

同じツールを使用する

セキュリティチームがDevOpsチームが使用するのと同じ継続的インテグレーション/デリバリーのツールに精通していることが重要です。Opsのチームにコードの書き方を教えたり、Chefのような構成管理ツールの使い方をDevチームに教えたりと、DevとOpsのチームが協働するのです。今度はこれをセキュリティで行う番です。

Jenkinsは最適な例です。開発者が既にJenkinsを使用してコードのテストやデプロイをしている場合、セキュリティチームにも使うように教えたらどうでしょうか。彼らがセキュリティテストに同じツールを使用すれば、すぐにそれをプロセス化することができます。

もう1つの素晴らしいツールはGauntltです。「Rugged DevOps」という用語についてはいくつか言いたいことがありますが、Gauntltのアイデアは良いものです。Gauntltのサイトで、

「Gauntltは、さまざまなセキュリティツールを提供し、セキュリティ、Dev、Opsチームで連携させて、堅牢なソフトウェアを構築します。これは、グループ間のテストとコミュニケーションを容易にし、実行可能なテストを作成して、デプロイプロセスとテストプロセスに投入できるようにします」

運用と開発プロセスの途中でセキュリティを導入するというコンセプトは基本的に妥当なものです。この方法では、セキュリティがデプロイを遅らせることはなく、問題が発見されたときのフィードバックループを強化できます。セキュリティチームはGauntltを使用してコードを書き、テストして、継続的デリバリーを容易にします。

スタティック解析を試みる

別のオプションは、Veracodeのようなツールを使ってスタティック解析を試みることです。セキュリティチームは、デプロイの前にコードを解析し、潜在的な問題をキャッチしようとします。スタティック解析は、コードを実行することなくソフトウェアを分析します。セキュリティチームは、デリバリーサイクルを中断することなく、潜在的な脆弱性を自動的にチェックすることができます。

インセンティブを合わせる

歴史的に、DevOpsとセキュリティを連携させるための課題の1つは、相反するインセンティブがあることでした。DevOpsチームはコードを素早く書き上げることが勝利です。セキュリティチームは安全なコードができたときが勝ちです。

所有権を提供する

私たちが抱えている一般的な間違いの1つは、開発にアクセスすることさえできないセキュリティチームがあることです。セキュリティチームがコードに対して直接的な所有権を持たない場合、DevOpsサイクルに緊密に統合されない可能性があります。

一方で、セキュリティチームに所有権を与え、コード内の問題を自分で解決する方法を教えると、サイロ化を免れ、よく油の効いたマシンの一部になることができます。たとえば、 Threat Stackはセキュリティ上の問題についてチームに警告することができます。セキュリティチームに問題を解決する方法を教え、構成管理コードにアクセスできるようにすると、システムに直接アクセスして変更を加えることができるようになります。

同様に、Chef は監査とテストのフレームワークであるInSpecというツールをオープンソース化しています。InSpecを使用すると、セキュリティチームは監査サーバにコードを記述し、コンプライアンスを確保できるようになります。これにより、プロセスに対する直接的な所有権が大幅に強化されます。そして、セキュリティチームの開発スキルを向上させることができます。論より証拠です。

これにアプローチする別の方法(特に専用のセキュリティチームを持たない場合)は、セキュリティ上の脆弱性が発生した場合に、バックエンドのエンジニアにコードの修正を担当させることです。エンジニアがコードの健全性に直接の責任を負っている場合、最初からセキュリティに重点を置く可能性が高いです。Threat Stackでは、2人のOpsと10人のバックエンドのエンジニアがオンコールに従事しています。製品に問題が発生した場合、そのコードを書いたのは通常バックエンドのエンジニアリングチームです。このレベルのコード所有は、最初から正しいものを構築するようなインセンティブを彼らにもたらします。

前に進むことは横に行くこと

セキュリティをシフトレフトすると、ビジネス全体の健康状態が改善されます。セキュリティチームが問題をキャッチしチケットを開いたあと、開発者やOpsの担当者が物事を修正するのを待つのではなく、彼ら自身で解決するような力を与えます。これにより、時間と人員が節約できるだけでなく、コードが安全かつ継続的にリリースされることが保証されます。この方程式が他のチームの仕組みやワークフローにどのようにしっかりと統合されているかを、より積極的に理解できるかは皆さん次第です。

上記のヒントは、組織の現実を「セキュリティをシフトレフトする」ための出発点です。セキュリティの多くの側面と同様に、新しいツールを導入するだけでなく、 文化的な変化も必要であることを覚えておいてください。それにより、正しい考え方、インセンティブ、フィードバックループを適切に実行することができるのです。

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

2019年11月20日  (更新日:2022年3月10日)     |    ベストプラクティス

サービスベースとチームベースのアプローチのどちらを選ぶべきか

by Mark Gabbard

インシデント対応プロセスをどのように設定していますか?

PagerDutyのアプローチは、お客様のインフラ、お客様の顧客向けアプリケーション、お客様の製品を総合的に調べることです。これらの項目を「サービス」と表現して、それらを総合した「ビジネスサービス」を構成します。この設定により、チームはサービスをより効率的に管理できるようになり、インシデントが発生したときに、応答者はより迅速にコンテキストを取得できるようになります。

まず、サービスについて説明しましょう。サービスは持続するように構築されており、通常、元々サービスを開発したチームよりも長生きします。言い換えれば、人々は出入りし、チームは常に再編成されるということです。また、サービスを所有するチームの変更は、年に一度だけとか、再編成時にだけに行われるのではありません。特定のプロジェクトでは、わずか数週間で新しいサービスを開始し、古いサービスを継承し、所有権を変更します。

そのため、インシデント対応プラットフォームをチームやサービスに合わせる(さらに悪いのはサービスをまったく提供しない)場合、チームの再編成が発生するたびにインシデント対応のセットアップ全体をやり直す必要があります。さらに、チームの変化に伴い、組織の知識と重要な分析データが失われます。悪夢のようですね。

そのため、PagerDutyはインシデント管理プロセスをサービスに合わせて容易に調整できるようにプラットフォームを構築しました。これにより、チームは時間の経過とともに成長し、変化することができ、サービスの状態とトレンドをより明確に把握できるようになりました。サービスのデリバリーや保守、改善に影響を与えることなく変更を行うことができるため、最終的にはダウンタイムの長期化と顧客への悪影響を軽減できます。

時間の経過に伴うビジネスインパクトやサービスの稼働状態、トレンドの可視性を向上

ほとんどの企業と同じように、インシデントプロセスのセットアップ、運用サポートや構成をチーム単位で行うことができます。つまり、チームベースのアプローチを取ります。これは、ITSM、DevOps、ITOpsのチームが混在し、ビジネスチームと技術チームがビジネスサービスを定義し、他の多くのチームも異なるサービスを持っていることを意味します。

では、チームベースの設定からサービスベースの設定にどのようにして移行するでしょうか。それは、ほとんどの人が考えるよりも簡単です。

最初に、顧客が特定のタスクや成果を実行するためにやり取りする製品やアプリケーションの部分にあたる最上位レベルのビジネスサービスを特定します。たとえば、「ログイン、ショッピングカート、検索」はすべてビジネスサービスです。次に、そのビジネスサービスを支える技術サービスを特定します。各技術サービスは、複数のチームが長期的なメンテナンスに携わっている場合でも、理想的には一度に1つのチームが所有し、開発する必要があります。

ビジネスサービスとそれをサポートする技術サービスを特定すると、さまざまな興味深いことができるようになります。たとえば、チームはビジネス全体で何が起こっているかをリアルタイムで確認できるようになり、単独の問題なのか、より大きな影響を与えているのかをよりよく理解できるようになります。これにより、問題が複数のチームやサービスにまたがる場合に、より適切に連携した対応が可能になります。

イベントが、環境内のサービスから別のサービスにルーティングされても、個々のサービスが環境にどのように反映するか、何が起こっているのかを誰もが簡単に伝えることができます。さらに、対応者はインフラ全体で発生している他のインシデントを把握できます。

例えば、Site Reliabilityエンジニアリングチームに所属していて、サービスが停止したという通知を受信したとします。同時に、データベースチームの別の対応者も同じ通知を受けました。あなたは、複数のサービスに関連するインシデントを表示できるため、それがデータベースの問題であることがわかり、データベースチームが対処することがわかった時点で、あなたによる問題の処理を中止できます。

ビジネスとビジネスニーズに対応

今日のほとんどの企業には、インシデント管理プロセスのためのチームベースの対応セットがあります。初期の段階では対応セットの設定は簡単ですが、成長と拡張に伴い、長期的な管理が実際には困難になります。なぜでしょうか。

このアプローチで生成されたサイロは、対応者に混乱をもたらします。インシデントが発生したときに、協調的で効果的な対応はより困難です。これは、対応者が実際に影響を受けたものを調べるために時間を費やす必要があるためです。何をすべきかを考える前に「サービスAとサービスBのどちらがページに表示されているのか、どの程度の対応が必要か」を考えるべきです。覚えておいてください。ほとんどのチームは少なくとも10の異なるサービスを所有しており、アラートが異なるサービスにルーティングされるようにイベント情報を整理しておくと、何が起こっているのかをよりよく理解するのに役立ちます。

これとは対照的に、技術サービスとビジネスサービスの橋渡しをする、サービス優先のアプローチを採用している組織は、特定のサービスの重要性に関するコンテキストを提供できるため、ビジネスと顧客に明確なインパクトを与えます。また、コミュニケーションのための共通言語を提供し、簡潔で実用的なステータスの変化を知る必要がある人と自動的に情報共有できるようにします(例:サービスAは見積りから現金までのシステムをサポートしているため、インシデントが発生した場合には、SLAがなく必須ではない内部サービスBより高いレベルの対応が必要、などの情報)。

チームベースのセットアップは簡単

前述したように、インシデント管理プロセスの構成と設定にチームベースのアプローチを使用すると、最初は簡単です。ただし、長期的にはマイナスの方がプラスよりも大きくなります。たとえば、チームベースのアプローチでは次のことはできません。

インシデントのビジネスインパクトをリアルタイムで評価する

サービスがアプリケーションの信頼性や安定性に及ぼす影響を分析する

問題の影響範囲を正確に評価する。これは通常、複数のサービスにまたがるので重要

重大なインシデント発生中に通知すべきビジネス関係者を迅速に決定する

加えて、チームベースのアプローチには、チームの変更や再編成に応じて変更を加える柔軟性がありません。さらに、組織の変更がある場合は常にチームとサービスを再構築する必要があります。

最適なアプローチ

インシデント管理プロセスを設定するため、チームベースのアプローチとサービスベースのアプローチのどちらを採用するか決定する前に、「オンコールを設定するのはなぜか」を考えてみましょう。

最も可能性の高い回答は、問題が発生したときに迅速に対応するチームや担当者が必要なため、ということです。また、多くの企業では、チームファーストのアプローチで構成を設定しています。これは、チームがあり、全員がオンコールローテーションに参加していることを確認する必要があり、この方法だと簡単に設定できるからです。

誤解しないでほしいのですが、チームは非常に重要です。しかし、インシデント管理の設定とサービスのセットアップを最初に行うことをお勧めする理由は、それによって次のことが得られるからです。

サービスの健全性を理解し、プロセスを改善するために必要な可視性

ホットスポットを特定するためのトレンドに関する洞察

どのチームがどのサービスをサポートしているかを簡単かつ迅速に確認する能力と、複数のチームを通過して問題のサービスに到達する前にそれらのレイヤーを理解する能力

結局のところ、企業が本当に気にしているのは、ビジネスを遂行できること、そして、迅速に対応する必要がある影響を与えるあらゆることです。そのための最善の方法は、サービスベースのアプローチを使用することです。サービスベースのアプローチを使用すると、何に取り組む必要があるのか、どのように優先順位を付ける必要があるのかを理解できるようになるため、問題のサービスを探すためにいくつものチームのレイヤーを掘り返すことで時間を無駄にすることがなくなります。

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

2020年9月9日  (更新日:2022年3月10日)     |    ベストプラクティス

アジャイルとスクラムに関する問題

「アジャイル」はソフトウェア開発でよく使われるバズワードで、一部の組織やチームはアジャイルを装っていますが、実際には全く違うことをしています。私はアジャイルコーチとしてのキャリアの中でそれを何度も見てきました。あるリーダーは、アジャイルの価値観を受け入れていると主張していましたが、エンジニアリングチームを細かくマネジメントし、開発者を操って長時間労働させるための方法としてアジャイルを利用していました。その結果、私たちの業界のエンジニアの中には、アジャイルソフトウェア開発を嫌っている人がいます。それは、エンジニアリング以外の人が彼らを操り、ソフトウェア開発をゲーム化するためにアジャイルソフトウェア開発を利用していると感じているからです。

この記事では、エンジニアがアジャイルやスクラムで経験する3つの「問題点」をお話しします。そして、悪質なアクターや誤解が蔓延している「アジャイルのBS」を切り取って、なぜこれらが全く問題ではないのか、その理由をお話しします。

始める前に、「アジャイルBS」を定義しましょう。

アジャイルBS:アジャイルの原則と価値観に沿っていないチーム、プロジェクト、または組織を指すときに「アジャイル」という用語を使うこと。例えば、アジャイルを装ったウォーターフォールや、実際には機能不全のプロセスを「アジャイル」という言葉で呼ぶこと。

この定義を念頭に置くために、チームまたは組織がアジャイルでないことを示す「アジャイルBS」フラグの例をいくつか示します。

エンジニアリングチームのメンバーがソフトウェアのユーザーと話したり、観察したりしていない

ユーザーからエンジニアリングチームへの継続的なフィードバックが行われていない

実用最小限の製品をできるだけ早く出荷して早期のフィードバックを得るよりも、完全なプロジェクト要件を満たすことを優先する

「アジャイルBS」の詳細については、国防総省のアジャイルBS検出ガイドをご覧ください。アジャイルの原則と価値観は、人々がアジャイルについて時々表現する問題、特にこの記事で指摘されている問題を解決するために作成されたのです。

問題1:アジャイルは、マネージャーが悪意を持って使用するための多数のプロセスとツールを提供するが、エンジニアが前向きの影響力を発揮するためのものはほとんどない

マネージャーがデイリースタンドアップを使用してチームメンバーを細かく管理できるのは事実です。また、マネージャーはスクラムチームのスプリントへの取り組みを「保証」と混同し、エンジニアにスプリントの目標を達成するために長時間労働を強要することがあります(問題2を参照)。しかし、これらはアジャイルソフトウェア開発の問題ではなく、マネージメントの問題です。そして、アジャイルソフトウェア開発では悪いマネージメントを克服することはできません。これは、アジャイルの原則と価値観が達成しようとしていることに対して、間違った期待をかけていることになります。

それでは、組織が適切な管理を実施しているとしましょう。どうすればアジャイルを受け入れることができるでしょうか。組織は、あらゆるレベルでアジャイルの原則と価値観を実践する必要があります。これには、リーダーシップによるアジリティへの取り組みが必要であり、アジャイルコーチのサポートを受けながらアジャイル変革の取り組みを通じて達成できます。PagerDutyの場合は、組織の効率を継続的に改善し、チームの可能性を最大限に引き出すシステム、プロセス、文化を構築、拡張するための専用のアジャイルリーダーシップチームがあります。

この「問題」と密接に結びついているのが、アジャイルはプロセスやツールよりも個人や相互作用を大切にしているということです。それは実際には何を意味するのでしょうか。

プロセスよりも人を大切にする。ソフトウェア開発を管理するのは人であってプロセスやツールではない

プロセスとツールに対する万能型のアプローチを求めるのは、ソフトウェア開発にはうまく機能しない

多様性を許さないプロセスや相互作用を妨げるツールに注意する。ガイダンスとガバナンスを考える

プロセスとツールについて考えるとき、アジャイルではないことを示す「アジャイルBS」フラグは次の通りです。

Doneの定義のようなプロセスの考慮事項が、エンジニアリングチームのトップダウンで定義されている

チームがプロセスソリューションを所有していない(例:スクラム対カンバンの選択)

マネージャーは、エンジニアを細かく管理する方法として、デイリースタンドアップとスプリントゴールを使用している

問題2:アジャイルは意図的に「見積もり」と「コミットメント」を混同し、エンジニアを操って時間外労働をさせる

この問題を2つに分けて考えてみます。

アジャイルは意図的に「見積もり」と「コミットメント」を混同している

チームの取り組みについて話し合う場合、言語は特に重要です。「スプリントへの取り組み」というスクラムの概念を説明するために、スクラムアライアンスとアジャイルアライアンスの共同創設者であるマイク・コーン氏からのアドバイスを紹介します。

「チームのコミットメントが保証と見なされないことが重要です。チームのコミットメントは最善を尽くすことです。私はコミットメントに、おおむね80%の時間を費やしてほしいと思っています。それは彼らが真剣に取り組み、時間の大半を占めるものでなければなりません。これは、チームが提供できるという内容をビジネス側が信頼するために必要なことなのです」。

ここで重要なのは、チームのコミットメントが保証と見なされないことです。チームは最善を尽くし、各イテレーションの終わりに達成したものと目標を比較し、それに応じてプロセスを適応させます。

エンジニアを操って長時間労働をさせる

時間外労働はアジャイルであることとは関係がなく、企業文化と関係があります。とはいえ、アジャイルマニフェストの原則は、アジャイルプロセスは持続可能な開発を促進するということです。これは、エンジニアが時間外労働を一切しなくてもいいということでしょうか? もちろんそんなことはありません。

エンジニアリングリーダーは、チームとともに適切な労働時間を設定することが重要です。たとえば、エンジニアリングマネージャーは期待を次のように伝えます。

私は誰もが週に40〜50時間働くことを期待します。これは通常、1日8時間の稼働で、月に1週間はオンコールであるということです。年に2回、私はチームに時間外労働をお願いするかもしれません。ただし、どうしても必要な場合を除いて、これをすることはありません。

マネージャーはチームに定期的に時間外労働を要求しているわけではありません。しかし、彼らはこれが毎年数回起こる可能性があるということを理解します。

持続可能な開発に関連して、チームや組織がアジャイルではないことを示す「アジャイルBS」のフラグは以下の通りです。

エンジニアリングチームがスプリントに取り組む場合、これは保証と同義である

スクラムチームは常にスプリントのコミットメントを守る

エンジニアリングチームは、スプリントのコミットメントを守るために、定期的に時間外労働をする

問題3:「コミットメント」というスクラムの概念は、2週間ごとに特定の量の完成した作業を実行することを意味する。これは、ソフトウェア開発について長期的な意思決定を望むエンジニアにとっては過度に敵対的である

スクラムチームが次のスプリントの計画を開始すると、彼らは顧客にとって最高の優先度を持つと決定された項目を引き出します。チームの長期的な決定は、チームの製品ロードマップで事前に計画されています。しかし、製品のロードマップは双方向です。プロダクトオーナーは、チームが解決すべき次に重要な問題を定義します。エンジニアがロードマップにフィードバックを提供し、チームが取り組むべきより価値のあるものがあると感じた場合は、それをプッシュバックするかどうかはチームのエンジニアにかかっています。

エンジニアが製品ロードマップにフィードバック(またはプッシュバック)するのはなぜでしょうか。

オンコールローテーションを行っているチームの場合、最近オンコールが特に騒がしくて苦痛を伴う場合、次のスプリントで最も価値のある作業は、インフラの改善を優先することです

チームが大量の技術的負債を蓄積している場合、問題が大きくなる前に、ロードマップを調整してそれに焦点を合わせる必要がある場合があります

チームがユーザーや利害関係者からフィードバックを受け取り、それによって提供している価値を向上させることができた場合、ロードマップを適応させてこのフィードバックに優先的に対応することが、最も価値のある仕事になるかもしれません

長期的な決定について考えるとき、チームまたは組織がアジャイルではないことを示す「アジャイルBS」のフラグをは次の通りです。

エンジニアリングチームには、プロダクトオーナーから解決すべき問題ではなく解決策が与えられる

エンジニアリングチームが製品ロードマップにフィードバックを提供する仕組みがない

成功とはなにか

組織が真のアジリティを受け入れれば、

エンジニアは、メトリクス(製品エンゲージメント、収益への影響、予測可能性など)、チームヘルスチェック、チームの回顧などのメカニズムを使用して、組織に前向きの影響を与えることができます。

形式の整ったスクラムとカンバンチームは、持続可能なペースで作業しながら、予測可能な価値を顧客に提供するとの信頼を得ます

エンジニアはフィードバックを提供し、製品ロードマップを調整して、常に最も価値のあるものに取り組むことができます。さらに、HackWeekを定期的に開催することで、組織にとって最も重要だと思うことに取り組むことができるようになります

学びを共有する

組織やチームが「アジャイル」を装っているのに、実際には全く違うことをしていることに気がついたことはありますか? PagerDutyコミュニティでは皆様からのご意見をお待ちしています。

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

2019年2月22日  (更新日:2022年3月9日)     |    ベストプラクティス

PagerDuty Postmortem(事後検証)ガイドのご紹介

「チームは重大インシデントと既に何時間も闘っており、あなたの調査は徐々に煮詰まっていきます。でもついにあなたは問題を特定することに成功し、グラフは改善し始めます。すべてのシステムが正常に戻ったとき、誰もがほっと息をついて、レスポンスコールを止め、そして再びこのインシデントについて考えることはありませんでした」。

…あるいはそう考えただけかもしれませんが。

先に進む前に、チームがやらなければならないことがもう1つあります。事後検証です。

なぜか?

事後検証は継続的に改善を進める文化を根付かせるのに役立つので、重要なのです。

事後検証なしでは、あなたとあなたのチームは自分たちがしていた正しい行いや、改善できる点、そして最も重要なこととして、何度も何度も何度も同じ間違いをしない方法を学ぶ機会を逃します。うまく設計された、責任を問わない事後検証は、あなたのチームがインフラとインシデントレスポンスのプロセスを改善するのを助けます。

ここで当社が効果的な事後検証(Postmortems)の実施方法に関する包括的なガイドを発表したことをお知らせしたいと思います。

このガイドのように、文化の変化のニュアンス、徹底した分析の実行方法の詳細、および失敗についての冷静で深い会話を促進するために必要な独自のスキルを網羅した資料は、他にありません。これらの概念がなぜ重要であるかを説明し、それらを実行することに関連する課題を説明し、そして責任を問わない事後検証を行うための実行可能な手順を提供します。

まだ事後検証をしたことがない人には、このガイドは、ご自分の組織に新しいプロセスを導入するのに必要とされる知識と戦略を提供します。事後検証の経験を持つ方には、自然任せでは陥りがちな非難の応酬に対処する方法、より深いインシデント分析のための新しい問い合わせの指針、事後検証の会議をより良く活用する方法、そして既存のプロセスを改善するための方法をたくさん学べるでしょう。

インシデントに対応している間は、チームは100%サービスの復旧に集中しています。 彼らは何かを最適な形で行う方法を考えたり、インシデントの原因を深く掘り下げることに時間と精神力を浪費することはできませんし、またそうすべきではありません。それが、事後検証の問題が不可欠である理由です。問題がユーザーに影響を及ぼさなくなったときに、事後検証の問題を反映するための平和的な機会を提供します。事後検証のプロセスでは、集中力を高め、学習の文化を浸透させ、そうでなければ失われる可能性のある改善の機会を特定します。

ちょっと待って、インシデントの事後検証って何ですか?

インシデントの事後検証(Incident postmortem)は色々な別名を付けて紹介されています。次のどれかならご存知かもしれません。

ラーニングレビュー

アクション後のレビュー

インシデントレビュー

インシデントレポート

ポストインシデントレビュー

根本原因分析(またはRCA:Root Cause Analysis)

事後検証とは、その根幹をなすもので、インシデントにつながった状況要因、インシデントに対応するために取られたステップ、そしてインシデントが2度と起こらないようにするために計画された作業を詳細に説明する文書です。事後検証プロセスには、検証結果について話し合い、それらの学習結果をより幅広い組織や顧客と共有するための会議も含まれます。

大きなインシデントを解決した後、その経験がまだみんなの心に新鮮な間に事後検証をすることを考え始めるべきです。PagerDutyでは、重大な問題が発生してから5日以内に事後検証の処理を済ませています。インシデントの解決がその発生時に最優先事項になるのと同様に、事後検証の完了は計画された作業よりも優先されます。事後検証の延期は、インシデントの再発を防ぐはずの重要な学習の開始を遅らせます。

責任を問わない事後検証

ITの専門家として、私たちは障害が複雑なシステムで起こることを理解しています。それは避けられません。そして、それが起こったときの失敗への対応は重要です。インシデントを引き起こしたとして個人を非難し罰したいという衝動は、将来のインシデントを防ぐために必要な知識の共有を阻むという意図しない効果をもたらします。エンジニアは、インシデントが発生したときには、非難を恐れて発言を躊躇します。この沈黙は、Ackまでの平均時間と解決までの平均時間を増大させ、インシデントの影響を拡大させます。

事後検証プロセスがシステムの改善と学習をもたらすためには、人的エラーを、体系的な問題が起こした症状として扱い、原因そのものだとは考えないようにする必要があります。ソフトウェア開発の複雑なシステムでは、様々な条件が相互作用して失敗を起こします。事後検証の目標は、どのような体系的要因がインシデントを引き起こしたのかを理解し、この種の失敗が再発するのを防げる行動を見つけ出すことです。

誰がミスを犯したかではなく、どのようにミスが犯されたかという点をブレずに検討し続けるべきです。これはエンジニアが罰を受ける恐れを排除することにより、起こったことについての客観的な説明を与え、事後検証の作業を正しく進めるために、Etsy(責任を問わない事後検証の先駆者です)のような多くの先行する組織に活用されている重要な点です。

継続的な改善の文化を望むことに賛成するのは簡単ですが、学ぶために必要となる、責任を問わない検証を実施することは困難です。失敗の本質の驚くべき性質は、それを素直に理解しない方向に人間を反応させます。情報を処理するとき、人間の心は無意識のうちに正確さよりタイムリーに対応しようと近道を取ってしまい、時々誤った結論を導きます。このガイドでは、事後検証分析を妨げる多くのCognitive biasesとそれらを克服するための戦略について詳しく説明しています。

あなたが次に重大なインシデントに遭遇したとき、あなたの対応は事後検証作業が済むまでは終わらないということを忘れないでください。大規模なインシデント対応は時々苦痛ですが、それはまたあなたのシステムとプロセスを学びそして持続的な改善をする素晴らしい機会になります。

私達の新しいガイドを見て事後検証プロセス(Postmortem process)に含まれるステップについての詳細を知ってください。また私たちは、Communityフォーラム(訳注:PagerDutyのサイトに飛びます)で、責任を問わない事後検証を実践するためにあなたが考えるテクニックについてお聞きしたいと思っています。

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

<  12  >