PagerDuty、新たなフィランソロピーパートナーとともに不公平を是正し、気候変動への対応に取り組む
PagerDutyは2年前にPagerDuty.org Fundを立ち上げ、タイムクリティカルヘルスの分野で資金調達し、より早く人々に届けることで命を救う手助けをするという使命を担いました。それ以来、世界はCOVID-19のパンデミックによる広範囲な影響と、人種的不公平に対する報いを受けました。このパンデミックの長期的な遺恨は、公衆衛生システムにおける構造的な不公平をさらに悪化させることです。これを受けて、PagerDutyは2021年、世界中の最も疎外されたコミュニティーへのワクチン配布に注力する団体のために100万ドルの資金、製品、技術サポートを調達しました。
私たちの世界、私たちが目指すもの
制度的差別と闘うために、私たちは健康格差に取り組む活動を、構造的人種差別の影響を受ける別の分野、すなわち気候変動と環境汚染の影響にも広げています。異常気象が私たちの日常生活や幸福に影響を及ぼすようになり、気候変動が私たちのコミュニティーの健康にもたらす害が明らかになってきました。これらの変化は私たち全員に影響を与えますが、最も被害を受けるのは、最も貧しい人々なのです。特に、パンデミックへの対応で見られた健康上の不公平は、人種、階級、性別による不平等が根強く、多くのグループが環境災害や気候変動の影響に対してより脆弱であることを映し出すものであります。有色人種、低所得者層、先住民族が、水質汚染や大気汚染、有害物質による被害を不当に受けていることを示す研究は増え続けています。レッドライン(訳注:経済面での人種差別)は50年以上前に禁止されましたが、その影響は今日も有色人種社会を苦しめています。歴史的にレッドラインのある地域は、レッドラインのない地域よりも気温が高く、木や緑地が少ないのです。さらに、これらの人々は、気候変動から最も深刻な被害を受ける可能性が高く、熱波、洪水、山火事、その他の異常気象の影響に備え、再起する能力が最も低いのです。
この不公平の中心にある根本的な原因である有色人種コミュニティーへの投資不足に取り組むためには、全ての人々、特に汚染と気候変動の影響を不当に、そして制度的に受けている人々の有意義な関与を中心とした環境正義のビジョンに焦点を当てる必要があります。この限られた機会に、私たちはより公平な未来を再構築しなければなりません。私たちは、環境危機の影響にレッドラインを引かない、社会的に公正なアプローチを必要としているのです。最も疎外された人々が環境災害や気候変動の影響、さらには新たな健康上の脅威から確実に保護されるようにするには、協力的かつ体系的なアプローチが必要です。
気候変動に関するフィランソロピーの分野を調査したところ、別の不公平があることが分かりました。気候変動に焦点を当てた資金提供者からの資金のうち、環境正義に取り組むBIPOC(訳注:黒人・先住民・有色人種)主導の団体に向けられたのはわずか1.3%でした。この不均衡から、Donors of Color NetworkはClimate Funders Justice Pledgeを作成し、全米最大の気候変動資金提供者に、より透明性を高め、気候変動資金の少なくとも30%をBIPOC主導の第一線のグループに展開することを公的に約束するよう求めました。
未来の世界的指導者への投資
公平性を高めるという目標のもと、私たちは全ての資金提供の取り組みにおいて、多様な指導者や有色人種のコミュニティーに力を与える組織への支援を意図的に行ってきました。PagerDuty.orgは、女性やBIPOCの指導者がいる組織への投資の歴史を踏まえ、環境と気候の正義に向けて活動する4つの組織に、合計25万ドルの無制限資金を投入します。これらの組織は全てBIPOCのエグゼクティブディレクターが率い、国内、地域、および国際的なコミュニティー主導の運動の一部を担っています。より公正な未来を擁護するためにオープンソーステクノロジーを使用している組織もあります。これらのパートナーは以下の通りです。
Earth Guardiansは世界中の環境、気候、社会正義の運動において力を発揮する指導者となるべく青少年を育成し、力を与えています。6大陸で数千人の若者が活動しており、Earth Guardiansは彼らの声とコミュニティーへの影響を増幅させるためのプラットフォーム、リソース、そしてつながりを持つ機会を提供しています。音楽、アート、文化を通じて、あるいは気候変動ストライキや集会を組織して、Earth Guardiansのユースリーダーは再生可能な未来を想像するよう、他の人々を鼓舞しているのです。
「組織は転換期を迎えました。1992年の設立以来、40歳以下のBIPOC女性が先導を務めるのは初めてのことです。PagerDuty.orgはEarth Guardianの転換期と活動を公的に支援してくださり、感謝しています。この寄付により、私たちはアート、ストーリーテリング、組織化、法的措置を使って力強い変化を生み出すために、若者のエンパワーメントを直接支援することができ、同時に私たちがグローバルコミュニティーとして直面している重要な問題に対するインパクトのある解決策を鼓舞していきます。」
-Catherine Mongella, Executive Director, Earth Guardians
Earth Hackのインクルージョンについてのビジョンは、世代間や多国間のつながりが生まれ、学生たちが環境活動の一形態としてハッカソンに参加するグローバルコミュニティーです。これまでのハッカソンでは、都市部のヒートアイランドなど不公平な問題の解決に取り組んできました。歴史的な差別的慣習であるレッドラインに起因する有色人種のコミュニティーに不釣り合いな影響を与える問題です。ハッカソンのイノベーション能力を活用し、オープンソースプロジェクトライブラリーは、何千人もの大学生が批判的思考に取り組み、潜在的な解決策を得るための出発点として役立っているのです。
「Earth Hacksは、PagerDuty.org Fundの寛大なご支援により、ハッカソンを環境活動の一形態として活用する私たちの活動を支援できることに感謝しています。この助成金により、例年よりも多くの学生を支援し、小さくても意味のある環境ソリューションの組み合わせを推進し、環境技術分野における正義に焦点を当てた文化の変化を促進し続けることができます。」
-Sanjana Paul, Co-Founder and Executive Director, Earth Hacks
OpenAQは、個人とコミュニティーをオープンデータでつなぎ、科学を発展させ、政策に影響を与え、大気汚染と戦う力を人々に与えることを使命とする非営利団体です。OpenAQ Platformは、世界最大のオープンソース大気質データプラットフォームであり、世界135カ国からの160億のデータポイントを集約・調和し、毎月1500万件のデータリクエストに対応しています。OpenAQ Platformは、よりきれいな空気のための世界的、地域的、ローカルなアクションを支える基盤として機能しています。また、多様なステークホルダーを集め、よりクリーンな空気のための公平なソリューションを触媒として、データ設計と行動計画を共同で開発しています。
「OpenAQは、PageDuty.orgの助成金を受けられることに感激しています。このパートナーシップによる支援は、きれいな空気を実現するためにデータへのアクセスがもはや障害とならない世界というOpenAQのビジョンをよりよく実現するために役立ちます。私たちは、大気質の低下に最も影響を受ける人々が大気質のデータにアクセスしやすくし、よりきれいな空気のための解決策をともに検討しようとオープンデータの力を利用する大気質の支持者を団結させることができるでしょう。」
– Chisato Fukuda Calvert, Interim Director, OpenAQ
The Solutions Project(TSP)は、全米の黒人、先住民、移民、女性、有色人種が主導する組織が生み出した気候正義の解決策に資金を提供し増幅する公的財団です。2021年、TSPは127の草の根団体に1000万ドルを助成し、助成対象に100万ドルのコミュニケーション能力開発を提供しました。これにより、石油生産の段階的廃止からパイプラインの阻止、風力タービンや電気自動車製造の開発、コミュニティーの太陽光発電や水システムの構築まで、目覚ましい成果を生み出しました。
「この運動は、多数の問題に同時に取り組む気候正義の解決策を現場で作り出している草の根組織とさらに協力するよう、フィランソロピーに求めているのです。TSPは、誰もが手頃な価格の住宅、環境に優しい良い仕事、資源への公平なアクセスを持つ世界を思い描いています。私たちがここに到達する唯一の方法は、最前線のコミュニティーと連帯して動くことです。PagerDutyのような業界のリーダーが、気候正義へのこの道を認識してくれることをうれしく思います。」
-Gloria Walton, CEO of The Solutions Project
COVID-19の大流行がもたらしたポジティブな結果のひとつは、資金提供パートナーに資金提供のスピードと柔軟性を高めるよう促したことです。PagerDuty.orgはこの点で確立された前例に倣い、私たちの助成金を使途不指定の資金として構成し、これらの組織が適切と考えるようにそのミッションを推進できるようにしています。また、PagerDutyの従業員、具体的には従業員リソースグループのリーダー、ソーシャルインパクトアンバサダーカウンシル、そして最も熱心な環境保護活動家たちが、私たちの選考プロセスに意見を述べ、私たちの決定に役立つ多くの多様な視点を提供してくれたことに感謝しています。
支援・奨励
パートナーの1団体であるEarth Guardiansが示しているように、若者主導の気候変動運動は、フィランソロピーにこの緊急事態に対応するよう働きかけています。パートナーから得た洞察と学習は、制度的差別に対処するアプローチを進化させるために、私たちの戦略に反映され続けます。私たちは、これらの優れた団体を支援できることを光栄に思うとともに、全ての人間と地球の健康を守るためのこの取り組みに参加される仲間が増えることを願っています。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
非インテリジェントなスウォームをコントロールしてインシデント対応を改善しよう
事件が起こる。物事がうまくいかない。システムが故障する。時には、予期しない劇的な方法で失敗し、重大な事故が発生することもあります。PagerDutyは、1つのインシデントとインシデントを非常に明確に区別しています。あなたの組織でもそのような区別をしているかもしれません。 (訳注:太字は重大インシデント、斜体は些細なインシデントという意味)
インシデントが重大かどうかの判断は、影響を受けるサービスの数、顧客への影響、インシデントの期間など、多くの要因、または特定の要因の組み合わせによって決まります。
これらの要素には、少なくともベースラインの遠隔測定と、技術エコシステムを構成するサービス間の関係性の把握が必要です。このベースラインがなければ、インシデントのトリアージにおいて、実際の影響やどこから手をつければよいかを知ることは困難です。
重要なデータがない場合、どうなるのでしょうか?次のようなデータがないと、インシデントに対応するのが難しくなります。
どのサービスが影響を受けるか どのサービスにどの程度の影響があるか そのサービスのオーナーは誰か
このようなデータがない場合、インシデント対応にスウォームアプローチを選択する組織もあります。
スウォーミングとインテリジェントスウォーミングの比較
スウォーミングとは、組織内の全員に問題が発生したことを知らせ、問題解決に貢献できる可能性の有無に関わらず、全員が参加できる大規模なウォールームや電話会議を開くインシデント対応のアプローチです。インシデントの影響を軽減するためには、適切な人材を適切なタイミングで動員することが極めて重要です。スウォーミングは、適切な人が適切な時間に適切な場所にいることとは正反対で、全員がずっと参加することです。
インテリジェントスウォーミングという言葉は、今月初めにお話しした、特にVIP向けの接客対応ワークフローを指す言葉として使われています。これはやや異なるアプローチで、最初にケースを拾ったチームメンバーが解決まで見届けることを指定し、問題解決を支援するために組織内のリソースを引き込む能力を持つものです。一般的なレスポンススウォームと関連しますが、インテリジェントスウォームの焦点は通常、単一の顧客であり、その体験を中心に据えることです。
一般的なテクニカルインシデント対応のためのスウォームは、建物の火災報知器のように、全員が厳戒態勢で対応することが期待されています。基本的には、何らかの知識を持つ可能性のある人全てにアラートが送信され、インシデントに参加するよう求められ、その後、誰がトリアージと修復を行えるかを見極める手間のかかるプロセスが開始されます。
組織はしばしば、自社のサービスやエコシステムについて十分な情報を持っていなかったり、ステークホルダーに情報を提供するための強力なコミュニケーション手段を持ち合わせていないために、群れをなしてしまうことがあります。何かが起こったとき、何が問題なのか、どこで起こっているのか、誰がどうすれば解決できるのか、誰も分からりません。だから、自分が何か重要な知識を持っているかもしれないと、誰もが動員されます。このため、スウォーミングは非常にコストがかかります。仕事は中断され、タスクやミーティングは頓挫し、リソースは有効でない場所に取り残されることになります。ほんの一握りだけが実際に対処できるインシデントへの対応のために、本来は障害にならない範囲で作業を続けて適切なアップデートを受け取れるはずの何百人もの人が動員されてしまうかもしれません。
スウォーミングアップも大変です。多くのレスポンダーがいる大規模な通報は、騒がしくて混乱することがあります。スウォーミングは、明確な調整や責任の所在が不明確なため、インシデントの復旧プロセスを遅らせることになります。中央の組織や意思決定権がない中で、あらゆる方向から情報が入ってきます。チームは、他のサービスへの影響を十分に理解しないまま、自分たちのサービスを復旧させようとするかもしれません。スウォーミングアップは、私たちがインシデントコマンドを明示的に実践している理由の一つです。混乱を減らし、事態を悪化させることなく、できるだけ早くインシデントを解決するためです。
スウォーミングは、自分たちのシステムが影響を受けていると判断された時点で人員を投入するのではなく、最初の警告からインシデントコールに必要な人員を常に配置できるとチームが考えているため、安心感があります。オンコール体制を改善することで、復旧に人員を割けないのではないかという不安を取り除くことができます。オンコールのローテーションを明確にし、責任分担を決めておくことは、いつオンコールの連絡が来るか分からないと心配するよりも、レスポンダーのストレスが軽減されるのです。レスポンダーは、特定の日や時間帯にオンコールシフトがあることを知っていれば、前もって計画を立てることができます。群発シナリオでは、必要な人材が不在になる可能性があります。彼らは24時間365日オンコールで対応できるわけではありません。
スウォームからの移行
スウォーミングからプロセスを改善するには、サービスとそれを所有するチームについてのチームの考え方を変える必要があります。PagerDutyでは、この実践を「フルサービスオーナーシップ」と呼んでおり、これについてはOpsガイドで詳しく説明しています。連携したインシデント対応という文脈では、サービスの所有権はいくつかのことを意味します。
1つのチームが、本番環境でのパフォーマンスを含め、そのサービスに対する全責任を持っている。 そのチームには、そのサービスに関する問題が通知されるための文書化されたプロセスがある。一般に、これはオンコールスケジュール。 そのサービスが消費する依存関係が文書化されている。
あなたの組織には、現在、明確なオーナーがいないサービスがあるかもしれません。それらは、もはや積極的な開発や注意を払う必要のない成熟したプロジェクトやレガシープロジェクトかもしれません。ベンダーと共同で保守している“棚から出してすぐ使える商品”(COTS製品)、SaaSソリューション、あるいは組織の変更で孤立した内部サービスかもしれません。サービスが本番環境の中にある場合は、ベンダーのアップデートを受信するためにチームの電子メールエイリアスを登録するだけでも、サービスを監視するチームを作る必要があります。あなたの環境で稼働している全てのサービスには、明確に責任を負うチームが必要です。これらのサービスは、インシデントに巻き込まれたり、セキュリティー更新などの作業を必要としたりする可能性がまだあります。組織によっては、レガシーエンジニアリングチームやプラットフォームエンジニアリングチームが、これらのサービスの責任者になっている場合もあります。
サービスを1つのチームに割り当てることで、環境内で誰が何を所有するのかに関する混乱を減らせます。チームは、自分が所有するサービスについて新しいメンバーを教育し、最も影響力のあるサービスのSLOに管理できます。サービスディレクトリーを作り、誰に通知すべきかを記載したチームのオーナーシップの構造を補うことで、組織内の全員に、問題が発生したときに相談できるリソースを提供するできます。PagerDutyでは、チームとエスカレーションポリシーをサービスに添付することで、これを実現しています。
エスカレーションポリシーは、サービス上のインシデントに対応するために、誰が利用可能だと期待されるかのガイドラインを設定します。この場合のレスポンダーは、影響を受けるサービスに精通し、問題のトリアージと修正を行うための適切なアクセス権を持つ人物であるべきです。
明確な依存関係モデルは、サービス間の関係を確立し、レスポンダー、サポート、ステークホルダーが、あるサービスでの事故が環境内の他のサービスにどのような影響を与えるかについて明確に把握できるようにします。PagerDutyはさらに一歩進んで、ビジネスサービスを提供し、技術サービスを互いにリンクさせるだけでなく、それらが貢献する顧客向け機能にもリンクさせます。全ての技術サービスとビジネスサービスは、サービスグラフに表示され、そのサービスのために現在オンコールしているチームメンバーへの便利なリンクも表示されます。
このインフラデータ(特に依存関係モデル)を構築することは、あるサービスに対して最新の状態に保たれていない場合、多くの労力を要することになります。しかし、バックエンドのサービスに対するインシデントの影響を完全に把握することは、その問題が発生しているサービスを消費している他のサービスが分からなければ不可能です。
カスタマーサポートチームも、この作業から利益を得ることができます。インテリジェントスウォーミングは、サポートチームがこれらの情報を全て手元に置いておけるかどうかにかかっています。顧客が解決策を必要とするとき、チームは全ての正しい情報を見つけ、適切な人材を動員できなければなりません。
インシデントコミュニケーションの改善
インシデント対応は、観客を楽しませるスポーツではありません。チェックやプロセスの実行を待ち、エラーメッセージを追跡し、再起動を待つ時間が長くなることがあります。この作業が行われている間は、あまり変化がありません。しかし、これらの作業が進行している間でも、修復に直接関与していない人々は、何が起こっているのかを知りたがります。強力なインシデントコミュニケーションプランがないことも、チームがスウォーミングに頼る理由の一つです。もし誰かが何が起こっているのか知りたければ、解決にどんなに時間がかかっても、コールに参加して聞くしかないのです。
重要なインシデントのための強力なコミュニケーションプランをあらかじめ決めておくことは、内部ユーザーが何が起こっているのかを常に把握できるようにすることと、外部ユーザーに情報を提供することの2つの機能を備えています。インシデント対応ガイドでは、インシデント発生時のコミュニケーションについて、「顧客リエゾン」と「社内リエゾン」いう2つの役割を明記しています。この2つのグループには、それぞれ異なるアップデートを行うことが予想されます。組織によっては、インシデントについて公表する内容を検討したり、特定の表現を使ったりする必要があります。そのため、テンプレートを作成し、特定のチームメンバーをコミュニケーション担当として任命することで、この作業を容易にします。社内向けには、他のチームが自分たちのサービスに影響があるかどうかを判断できるように、より詳細な情報を提供することになるでしょう。
最良の計画は、全てのステークホルダーに定期的に情報を提供することを前提にしています。早めに、そして頻繁にコミュニケーションすることで、状況が改善され、問題が解決されたときに、全員に知らせることができます。
NOCで群れる必要はない
第一線のレスポンダーが総合的な担当をするNOCチームである場合、最新のインシデント対応モデルに移行できます。サービスオーナーシップを明確にしていれば、NOCがインシデントを解決できない場合、複雑な問題をサービスチームにエスカレーションできます。サービスAを担当するチームのオンコール中のレスポンダーを呼び出すことは、組織全体からさまざまな人を集めるよりもはるかに簡単です。
まとめ
対応方法を近代化することで、組織の時間とリソースを節約できます。SAPのようなPagerDutyの顧客は、必要なときに必要なレスポンダーだけを動員し、最も効果的な対応を提供することに集中できるという利点を享受しています。
もし、あなたのチームが解決までの時間を短縮し、大規模なスウォームコールの必要を抑制する方法をお探しなら、当社のインシデントレスポンス運用ガイドのリソースをご覧ください。フルサービスオーナーシップを実現するために必要なことは何でしょうか?当社のビデオをご覧になり、コミュニティーフォーラムで同じ考えを持つ人々と話し合ってみてください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
Event Orchestrationの活用でノイズを減らし、次善の策を講じる
お客様からは、管理しきれないほどの大量のノイズや複雑性に対処しているため、根本的な原因を突き止め、迅速に解決することが難しいという声をよく聞きます。ノイズの選別、イベントの処理、コンテキストの収集に費やす労力は、多くの時間を浪費することになります。
そこで私たちは、Event Orchestrationを発表し、Event IntelligenceとDigital Operationsをご利用中のお客様に月曜日から提供し始めました。
PagerDutyのEvent Orchestration担当シニアプロダクトマネージャーであるFrank Emeryに、この機能を構築した理由と、お客様の行動やフィードバックがどう開発の方向性を決定したのか、その背景を詳しく聞いてみました。
Q: 新機能のEvent Orchestrationについて教えてください。
A: PagerDutyのプラットフォーム全体で見ると、20%のインシデントが5分以内に解決されています。解決が難しい大きなインシデントを5分以内で解決できることはありません。このことから分かるのは、インシデント対応には、診断テストの実行やサーバーの再起動など、必要ではあるが手作業に近いプロセスが存在し、それがチームの時間を奪い、生産性や集中力を低下させていることです。このようなケースでは、的確な自動化によってインシデントレスポンス時の手順を短縮することが可能です。場合によっては、インシデントを担当から外すこともできるかもしれません。これらのユースケースを、解決時間が15分や30分のインシデントの原因となる反復タスクに拡大すると、時間の節約、生産性、集中力の向上の可能性はさらに高まります。
それは、「インシデント発生時にお客様のチームが常に行っている手作業や繰り返しの作業に費やす時間を減らすために、当社のプラットフォームを利用できるようにするにはどうすればよいか」ということです。オートメーション化することで、すぐ処理できるイベントがレスポンダーの手を煩わす数を減らし、実際に彼らの専門知識が必要なインシデントに時間を割くことができるようにするには、どうすればよいでしょうか。
Event Orchestrationについて考えるとき、もしお客様がルールを設定する方法をより柔軟にし、より多くの自動化機能を前もって使用できるようにすれば、チームが通知を受ける前に、これらのすぐ解決策が分かるタスクをできるだけ多くカバーすることができるのではないでしょうか。
Q: Event Orchestrationは、Event Rulesとはどう違うのですか?
A: 私たちがうまくやったのは、Event Rulesを利用して、イベントの取り込みパイプラインに直接設置する意思決定エンジンを構築したことです。Event Orchestrationでは、複雑なロジックを備えた新しい条件言語を使い、条件に基づいて次善のアクションを広範に起動できます。ある例では抑制、ある例ではルーティング、あるチームではリアルタイムに取り込まれる自動診断や自動修復などの自動アクションを起動したいと思うかもしれません。
オーケストレーションで特定の状況を処理するように設定すると、マシンはロジックを使って状況を識別し、その状況に基づいて対処方法を決定します。これにより、誰かが通知を受ける前に、意思決定エンジンがこれらのタスクのいくつかを処理する道が開かれ、そもそも人間が必要な場合には、インシデント対応プロセスに増員し始めることができます。
Q: Event Orchestrationの利用を検討している人にとって、ハードルの低い利用例を教えてもらえませんか?
A: お客様のことを考えると、まず2つの使い方のどちらかをされることが多いでしょう。
1つ目は、ノイズリダクションです。ノイズは非常に一般的な問題で、スタックを監視するために接続されるあらゆるツールと、それらがどうアラートを送信するかを考えれば驚くことではありません。私たちは、重複排除や抑制といった他の機能や、インテリジェントアラートグルーピングといったMLオプションも用意していますが、お客様の中には、より正確な情報を得たいと考えている方もいらっしゃいます。ノイズリダクションにEvent Orchestrationを使うと、ユーザーは正確なルール条件を利用して、非常に多くのターゲット状況を設定し、チームのためにノイズをそらし、統合、抑制して、重要な信号のみを通過させることができます。
2つ目は自動化です。自動化がどこまで高度になるかは、運用の成熟度によって異なります。インシデントレスポンスの初期段階を自動化できる可能性は非常に高く、その多くのステップは実際に非常に繰り返されることが多いものです。
最もノイズの多いサービスについて考えてみてください。そのサービスのインシデントのうち、同じ初期診断手順を必要とするものがどれだけあるか考えてみてください。エンジニアからよく聞く話ですが、障害が発生すると必ず電話がかかってきて、問題解決のために誰かが何かを始める前に、毎回このような手順を踏まなければならないそうです。通常、これらのステップはスクリプトを実行したり、正しいコンテキストを見つけるために情報を収集したりするものです。多くのシナリオで必要とされる、よく知られた反復タスクである診断の自動化から始めることが、手軽ですぐに成果を上げやすいシナリオだと言えます。
もっと詳しく知りたいですか?Event Orchestrationの詳細については、ナレッジベースの記事、またはこちらのデモをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
最適なインシデント対応ソフトウェアの選び方
デジタルエコシステムの複雑化に伴い、インシデントがかつてないほどのスピードで発生しています。さらなる負担に対処するため、インシデントレスポンダーは、労力とノイズを減らし、適切な人材を適切なタイミングで現場に投入する、拡張性と再現性のあるインシデント対応プロセスの確立を支援するソフトウェアに注目しています。
最高のインシデント対応ソフトウェアは、インシデントのライフサイクル全体に対応します。アラートノイズの低減から詳細なインシデント分析の提供まで、インシデント対応ソフトウェアは、インシデント解決のための自動的および人的要素の両方をカバーし、収益の損失、顧客体験の低下、チームの燃え尽きなどを防止する必要があります。
インシデント対応ソフトウェアとは?
レスポンダーは、インシデントを迅速に解決する必要があることを理解していますが、リソースと時間の不足により対応に手間取っています。インシデントの特定、解決、予防に対する最新のアプローチがなければ、何が本当に修復を必要としており、何が後回しでよいのかがわかりません。このため、非効率的で部分的にしか効果のない消火活動のサイクルから抜け出せず、長期的なイノベーションと計画的な業務への投資が妨げられています。
インシデント対応ソフトウェアは、インシデントが発生するたびに、チームがリアルタイムで適切なアクションを取ることを支援し、重要なインシデントの迅速な解決と今後の発生を防ぐための知識の習得につなげます。さらに、ステークホルダーや経営陣に情報を提供し、顧客への影響を軽減することができます。チームは、合理化されたエンドツーエンドの対応によって、より大量のインシデントを管理し、レトロスペクティブ(振り返り)によって対応プロセスを継続的に改善することができます。
インシデント対応ソフトウェアの特徴
レスポンダーの動員
インシデント対応ソフトウェアは、業務上の問題やインシデントが、常にリアルタイムで対応できる適切な個人またはチームに送られるようにする必要があります。理想的には、レスポンダーはどこにいても、どのデバイスからでも、問題に対する通知を受け取り、直ちに行動を起こすことができる必要があります。
レスポンスの自動化
チームは、どのような優先度のインシデントに対しても、適切な対応を設計する能力と自律性を備えていなければなりません。自動化能力は、診断から自動修復に至るまで幅広く対応する必要があります。つまり、レスポンダーはインシデントに関する正しい情報を即座に得ることができ、自動化によって人の介入なしにインシデントを解決できる可能性さえあるのです。
ステークホルダーとのコミュニケーション
今日のインシデント対応においては顧客への影響を軽減するために技術チーム以外の協力も必要です。経営陣、サポート、さらにはマーケティング、法務、営業などのステークホルダーは、レスポンダーの作業を中断することなく状況を把握する必要があります。インシデント対応ソフトウェアは、レスポンダーが対応プロセスをできるだけ中断させることなく状況の更新を伝えられるようにする必要があります。
統合化する能力
チームは、インシデント情報の収集、進捗状況の記録、および全体のコミュニケーションを行うために、さまざまなツールを使用しています。インシデント対応ソフトウェアは、モニタリングツール、ITSMツール、チャットやビデオ会議などのコラボレーション・コミュニケーションツールなど、チームが既に使用しているツールと統合されていることが理想的です。
オペレーショナルインサイト
インシデント対応ソフトウェアは、時間の経過とともにチームが向上するよう支援する必要があります。アナリティクスは、過去のシステムパフォーマンスの全体像を把握することで、よりスマートでリアルタイムの意思決定を可能にします。
インシデント学習
振り返りは、合理的な学習プロセスを提供し、インシデントの解決と予防をより効果的に行えるようにします。インシデント対応ソフトウェアでは、タイムラインを作成し、インシデントの重要な進展を文書化し、今後の改善計画を立てることができるようにする必要があります。
インシデント対応ソフトウェアのメリット
レスポンダーの健康と体験の向上
インシデント対応ソフトウェアを導入することには、多くのメリットがあります。重要な利点の1つは、レスポンダーの健康と体験です。オンコールで対応することは大変なことであり、疲弊し、燃え尽き症候群や離職につながる可能性があります。ノイズや労力を制限するインシデント対応ソフトウェアがあれば、最前線にいるチームは、消火活動の時間を減らし、イノベーションに多くの時間を費やすことができます。
社内コミュニケーションの向上
インシデント発生時のコミュニケーションは重要であり、技術チーム内や技術チーム間だけではありません。ビジネスチームもインシデントにどう対応すべきかを知っておく必要があります。営業はデモを延期すべきか。マーケティングはキャンペーンを一時停止すべきか。サポートはチケットの増加に備えるべきか。インシデント対応ソフトウェアによって、チームはこれらの社内ステークホルダーとコミュニケーションを取り、全員が同じ見解を持つことができます。
お客様との信頼関係の向上
顧客の期待はかつてないほど高まっており、インシデントは信頼を損なって解約につながる可能性さえあります。インシデント対応ソフトウェアを使用すれば、対応プロセスが合理化され、MTTRが向上し、顧客のためにサービスをより早く復旧させることができます。さらに、インシデントの状況について顧客と積極的にコミュニケーションをとり、信頼と透明性を高めることができます。これによって、競合他社に差をつけることができます。
結論
インシデントの量と複雑さが増すにつれて、組織は収益の損失と顧客体験の低下のリスクにさらされています。インシデント対応ソフトウェアは、チームが重要な業務に迅速かつ適切に対応し、関係者全員の体験を向上させるために役立ちます。インシデントは避けられないものですが、最高のインシデント対応ソフトウェアは、対応者がサービスを迅速に正常な状態に戻し、組織全体に拡大する改善を行うために必要なツールを提供します。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
PagerDutyのピープルファーストのコミュニティーへの取り組み
ピープルファースト(人間第一)は、私たちが日々実践している哲学です。今日は、社員と、そして世界中に広がるコミュニティー作りを通して、私たちが実践している進化した方法をご紹介します。
デュートニアン(訳注:PagerDutyの従業員)にとって2年前は20%だった在宅勤務が、今では75%に達しています。分散型が私たちのニューノーマルです。全新入社員が、ハイブリッド、オフィス内、好きな場所と、自分に最も適した勤務形態を選ぶことができ、働く場所に究極の柔軟さが与えられています。
大切な時間をつくる
デュートニアンの生活を豊かにするために、私たちは社交、コラボレーション、ネットワーク、そして豊かなコミュニティーへの参加をより簡単にできるようにしています。
”Donuts”と”Casual Collisions”の2つは、仮想環境での偶然の出会いや雑談を再現するため取り組みです。Donutsは、Slackのチャンネルにボットを追加し、チャンネル内でランダムにペアリングを行い、ソーシャルチャットを行えます。Casual Collisionsは、このコンセプトを全社的なペアリングに拡大したものです。
PagerDutyは社会的なつながりだけでなく、年2回のHackWeekの伝統を発展させ、現在はバーチャルで行われ、全ての参加者にとって公平な体験となっています。HackWeekは、デュートニアンにとって、普段は会うこともなく、ましてや一緒にプロジェクトに取り組むこともないような会社の人たちと、革新的なアイデアを追求するチャンスなのです。
PagerDutyの価値観でつながる
PagerDutyの目的、ミッション、ビジョン、バリューは、デュートニアンをグローバルに繋ぐものです。私たちは、未来を築き、より公平な世界を描くために、時間と効率でチームに力を与えるために存在しています。この信念は、従業員体験も含め、私たちが行う全てのことに適用されています。
ワークプレイスエクスペリエンスチームのプログラムであるVibeは、デュートニアン同士のつながりを構築・強化し、私たちのブランドやコアバリューとのつながりを感じられるようにするためのものです。Vibeで最も人気のあるイベントの多くは、Social ImpactやEmployee Resource Group(ERG)といったチーム横断的な取り組みで、還元、コラボレーション、ID&Eといった当社の真の価値志向を反映しています。例えば、STEP-temper initiative では、世界中の32チームがチャリティのために1カ月間のフィットネスチャレンジに参加し、素晴らしい非営利団体”Humanity Matters”に合計26,000ドルを集めました。
今年、Vibeは四半期ごとに異なるPagerDutyの価値を、恩返しの要素と結びついた楽しい社会活動の組み合わせによって実現しています。バーチャルコンサート、コンテスト、体験型アクティビティー、そして「Bring Your Child to Work Day」のような家族全員で参加できる機会も用意されています。また、チームから寄せられた快適さや要望をもとに、対面式のイベントも数多く開催する予定です。
また、2カ月に1度のガイド付き瞑想や、Slackでの#WatercoolerWednesdayディスカッションスレッドなど、Vibeが継続的に行っているプログラムも引き続き実施していく予定です。
PagerDutyはコミュニティーを向上させる
PagerDutyのコミュニティーは、デュートニアンを遥かに超えて、私たちの顧客、パートナー、そして私たちが生活し働くコミュニティーを含んでいます。私たちの1%誓約コミットメントの一環として、私たちは従業員の労働時間の1%を地域社会とグローバルコミュニティーの変化を加速させるために提供すると誓約しています。
私たちの社会貢献プログラムは、従業員のスキルや関心を結集してコミュニティーのニーズに応え、信頼とより大きな公平性を構築することを目的としています。 その例として、Volunteer Time Off(VTO)、Technical Pro Bonoプログラム、Givingプログラムの3つがあります。
社員は毎年20時間の有給休暇を取得し、自分の好きな団体や活動に時間やスキルを捧げることができます。子どもの学校でのボランティア、地域の非営利団体への支援、投票関連やメンター活動への参加など、さまざまな活動が行われています。社員はボランティアに参加した時間と影響を記録すると、PagerDutyから資金を得て、自分にとって重要な活動に寄付できます。
私たちは、毎年恒例のカンパニーキックオフ(CKO)で集団ボランティア活動を行い、力強い1年をスタートさせています。今年のCKOでは、デュートニアンは18の仮想プロジェクトをサポートし、公平性を高め、存在感の薄いコミュニティーの機会を拡大し、PagerDutyの非営利顧客とローカルパートナーの影響をさらに拡大させました。例えば、パートナーであり非営利団体であるWeRoboticsがFlying Labs Networkの全メンバーをうまくまとめるために最適なコミュニケーションツールを特定するなど、パートナーが直面している課題に対する解決策のブレインストーミングを支援しました。
通年、ERGや各地域で社会貢献活動を推進する社員のグローバルネットワークであるCommunity Respondersと協力し、社員なら誰でも参加できるドロップインの仮想ボランティア機会を毎月設けています。
PagerDutyの社員は、Technical Pro Bono programを通じ、私たちのプラットフォームの知識を活用して、非営利団体のお客様のデジタルトランスフォーメーションの過程をサポートしています。昨年秋には、異なるチームや地域のPagerDutyの社員が、ワクチンの公平性を高めるために最前線で活動する3つの非営利団体とパートナーシップを結びました。
PagerDutyカスタマーサクセスマネージャーのJon Honariは、Technical Pro Bonoプログラムの経験について、次のように語っています。
「WeRoboticsと一緒に仕事をすることで、PagerDutyは単なるソフトウェア会社ではなく、変化と善のためのファシリテーターであると感じるようになりました。WeRoboticsのチームは、ドローンの助けを借りて予防接種や医療用品を届けることで、世界の最も遠隔地に住む人々が健康を維持できるようにすることを目指しています。PagerDutyが、困っている人々の幸福のために直接インパクトを与えることができるのは素晴らしいことであり、彼らのミッションの一翼を担えたことに感謝しています。
また、従業員には、危機対応活動、PagerDuty.orgパートナー、および自分にとって個人的な原因を支援するための資金提供や企業マッチングキャンペーンに参加する機会もあります。2021年、デュートニアンは412の活動を支援し、デュートニアンの92%が当社のソーシャルインパクトプログラムに参加しました。
詳細は、PagerDutyが近日中に発表する「2021 Impact Report」でお楽しみください。
PagerDutyとPeople-Firstコミュニティーへの参加にご興味がありますか?
私たちは採用中です。PagerDutyでの生活については、採用情報ページと、このピープルファーストシリーズのブログ1と2をご覧ください。PagerDutyの拠点は、リモートでの勤務のほか、アトランタ、リスボン、ロンドン、サンフランシスコ、シドニー、トロントにあります。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
成長の機会を与えてくれた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社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
PagerDutyのスケジュール設定をしてみました
ConfigurationからScheduleを選択します。
「New On-Call Schedule」で新しいスケジュールを追加できます。
まず、 「Time zone」を日本に設定して、Layerを追加していきます。
レイヤーを順番に設定していきます。
レイヤー1では、1人の担当者が日中の時間帯に交互に担当するよう設定してみました。
レイヤー2では、それ以外の時間帯を2名で設定してみました。
最終的なスケジュールは、以下になりました。
簡単なUI操作だけで、柔軟なスケジュール設定ができますね。
また、スケジュールのOverride機能を使うと例外的なスケジュールも組み込むことができるので、非常に便利です。
いかにして優秀なエンジニアになるか パート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社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。
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社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。
チームの健全性に関する驚くべき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社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらです。
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カスタマーサポートチームがインシデント管理をどのように活用できるか
「インシデント管理」と聞くと、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年間で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年間(そして多くの)の学習の成果がここにあります!
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
インテリジェント対応と自動化で、少ない労力で多くのことを行う
良くも悪くも、私たちの社会はは効率化に取りつかれています。オンラインバンキングや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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
セキュリティスタックに入れておくべき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とインシデントのライフサイクルに関する最良のアプローチを採用してください。多くのツールはユニークな機能を提供しますが、選択したツールが他のツールともうまく機能することを確認してください。問題を検出する際に最大の馬力を発揮できるだけでなく、最も重要なときに指先で適切なデータを取得できるようになります。
- PagerDuty最高製品開発責任者による「AIと自動化が実現するオペレーショナル・エクセレンス」講演録画が公開
- PagerDuty、新しいアップデートで運用効率を向上
- PagerDuty 8月の製品アップデート情報
- Juneteenthを受け入れる:インクルージョンへの旅
- Custom Fields on Incidentsのユースケーストップ5
- ゼロトラストセキュリティーの正体と、気にしておくべき理由
- 5 年間の社会的影響: 公約 1% に対する進捗状況を振り返る (そしてこれから)
- AIOpsと自動:Forresterの主席アナリストであるCarlos Casanova氏をゲストスピーカーとして迎えた対談
- Runbook Automation for Incident Resolutionの新製品トライアルを活用する
- PagerDuty Operations Cloudに生成AIを投入