Category
ベストプラクティス

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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
ベストプラクティス
2018年2月20日  (更新日:2022年3月9日)     |    ベストプラクティス

デジタル経済の世界で顧客サポートがより良いサービスを提供できる5つの方法

顧客サポートチーム はあなたの組織の顔です。顧客と最も関わるグループであり、顧客のロイヤリティ を形成する上で重要な役割を果たします。顧客サポートを 適正にしましょう。これは、既存の顧客に製品を簡単にアップセルおよびクロスセルしたり、将来のバージョンの製品に対応するためのアイデアを提供する方法になります。 顧客サポートはさらに、他のチームを一つにし、誰もが顧客に集中し続けるようにするチームでもあります。

顧客サポートの重要性を意識して、日々の仕事を行うときにサポートチームが最高の経験を確実に得られるように配慮することが重要です。 それが今日、話すことです。

  1. サポート・アプリケーションを1ボードに統合する

サポートチームは通常、それぞれ異なるタスクに特化した複数のアプリケーションを使っています。 サービス管理にはServiceNow 、問題追跡にはJira、コミュニケーションにはSlack、 インシデント対応と解決のためのPagerDuty、その他にもモニタリング、 顧客とのコミュニケーション 、レポート作成などのツールを使用できます。 担当者がこれらのアプリを切り替え続けるのにうんざりするようになることがあります。 さらに悪いことに、これらのアプリで矛盾する情報が表示されると優れた顧客サービスを提供することが困難になることがあります 。

もっと良いアプローチは、これらのアプリを統合して、担当者がログインしているアプリに関係なく統一された形で操作できるようにすることです。 サポートチームによって使われる主なアプリのほとんどは、 他のトップツールと統合するためのAPIと統合ガイドを提供しています。 ソリューション全体を統合する能力は、顧客がソリューションを選択する際の重要な差別化要因となっています。

これらのアプリケーションを統合することで、サポートチームは、Slack内からPagerDutyインシデントを作成し、Jiraを使用してエンジニアリングチームにフォローアップを求めて問題を解決させることができます。 そこから、ステータスをServiceNowに同期させることができます。 サポートチームは、電子メールやソーシャルメディアなどの任意の優先メディアを介して顧客とやり取りすることができます。 すべてこれがシームレスになり、サポートスタッフの仕事が楽になります。

  1. ダッシュボードを使って応答時間を短縮する

「重要度の低い指標」(バニティ・メトリクス)はサポートチームの悩みです。担当者が1日に何枚のチケットをクローズするかを基に評価された時代は過ぎました。 今日のメトリクスは、担当者中心ではなく顧客中心です。 MTTR(平均回復時間。mean-time-to-resolution)のような指標のほうが、単に顧客に対応した回数より重要です。

これらのメトリックをダッシュ​​ボードに表示すると、チームは適切な方向へ進んでいるときには元気付けてくれますし、状況があまりうまくいかないときには警告してくれることになります。 緑色、黄色、赤色などのカラーコードを使用して、トップレベルの指標や個々のインシデントのステータスを表示することで、即応性を高めるのに役立ちます。 PagerDutyやServiceNowなどの先進的なツールでは、ダッシュボードとビジュアライゼーションが事前に設定されています。そうしたツールに必要なのはデータを入力することだけで、それも柔軟かつセルフサービス的な方法で、簡単かつ迅速に行えます。

  1. マルチタッチサポートでSLAを維持する

顧客は複数のデバイスと通信チャネルを使っており、チャネルの多くにあなたもいてくれることを望みます。電子メールだけでなく、ライブチャット、電話のホットライン、製品フォーラム、さらにはソーシャルメディアの会話が、サポートの会話が行われる場所です。これらのすべての会話をサポートツールに統合し、効率的に管理できる必要があります。

これを行う1つの方法は、チャネル間の通信が統合されていることを確認することです。 たとえば、 Live Call Routingを使い、電話をかけてすぐにインシデントを報告できるようにし、誰でもすぐに適切な対応者に連絡できるようにすることで、インシデントを迅速に受信したり解決したりできるようになります。

マルチタッチサポートの最大の利点は、異なる顧客に異なるSLAを設定できることです。 たとえば、プレミアム顧客のみがサポートのための24時間×7日専用でつながる内線番号を取得し、他の顧客はフリーダイヤル番号にアクセスさせるようにできます。 このようにして、すべての顧客に対して差別化を進め、すべての顧客が自分が選んだサービスレベルに満足していることを確認することができます。

  1. インテリジェンスによるカスタマエクスペリエンスの管理

顧客があなたに連絡するために使えるチャネルの数が多いと、問いあわせの洪水を起こす可能性があるので、その数は顧客サポートチームの目標ではありません。 理想的には、着信チケットの数を減らし、インシデントを減らし、顧客サポートへ連絡することを顧客にとっての最後の手段にしたいと考えます。 これは、顧客が体験することを事前に計画するのに役立ちます。 セルフサービスモデルは、ほとんどの組織が好むものです。 しかし、これには最新の知識ベースやドキュメンテーション、活発なフォーラム、製品の関係する場所での小技やヒントが必要です。長期的な努力を必要とするので時間がかかります。

顧客体験の管理を始める最善の方法は、顧客が即時対応を期待できる自動化ルールを設定することです。 たとえば、最優先のインシデントには24×7でつながる電話番号が必須です。 他のインシデントは4時間のターンアラウンドタイム(TAT)がかかる可能性があるとしておきます。 同様に、インシデントがキューにヒットしたら、チーム内でどうルーティングするかを決めるための自動化ルールを設定できます。PagerDutyは、スケジュールの設定とエスカレーションの自動化に優れています。これにより、チームがバーンアウトを起こさずに優れたサービスを顧客に提供できます。

  1. 継続的改善のためにCSATを測定する

顧客サポートの有効性を追跡することが重要です。 そのためには問題が終了した直後にユーザーに、サポートのレベルに満足したかどうかを尋ねる必要があります。 CSAT(顧客満足度)を測定すると、時間の経過とともに改善状況を追跡するためのベンチマークが得られます。 上記の提案をすべて実行することで、CSATが正しい方向に推移するのが見えるはずです。

顧客サポートは、あなたの製品や組織について顧客がする経験にとって本質的に重要なものです。 ワールドクラスの顧客サービスを提供するためには、サポートチームは仕事に最良のツールが必要です。 しかし、それは終わりではありません。これらのツールをシームレスに統合し、独自の機能を使ってサポートプロセスをより簡単に、より速く、より効果的にする必要があります。 PagerDutyのようなプラットフォームは、このレベルのカスタマーサポートを可能にしています。

顧客サポートチームがインシデント管理によりオペレーションを最適化する方法の詳細を知りたい場合は、当社のeBookをご覧ください。(訳注:eBookは英文です。)

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

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

インクルーシブなコミュニティを育成する3つの方法 from Jennifer Tejada

「魚は頭から腐る」という言葉を知っていますか?それは、失敗の責任が組織の最上位にあることを意味します。企業が不安定になるのは、リーダーシップに責任があります。逆に、成功する文化は企業のリーダーの管理下にあります。その基調はトップにあります。その文化が定義されるのは、人が受け入れたいと思う最も低いレベルの行動で定義されます。指導者として、私たちは目標とBHAG(big, hairy, audacious goals:大きく、扱いにくい、大胆な目標)のことだけでなく、組織のテンポ、許容度、限界を決定します。高みに向かう私たちの旅で、妥協したくないことは何ですか?私たちが構築するだけでなく、保護すべき価値観や原則は何ですか?真の成功は、あなたが創造する価値と創造する方法の両方によって特徴付けられます。複数の人々が関わっているときは、人々はいつも関わっているものですが、全てを賭けて勝つという選択はありません。

高成長中のクラウド企業のリーダーとして、私は勝利のことを簡単に考えています。ユーザーが勝利したら、私たちも勝ちます。当社の唯一の「ヒーロー文化」は、ユーザーや顧客を大成功に導こうとみんなで動くことであり、利害関係者の目に見えるヒーローであることです。

ダイナミックで高速で競争の激しい市場でお客様に革新を起こすには、PagerDutyでキャリアを積む間に最高の仕事をする人材が必要です。私たちの人とチームが繁栄するためには、明白な目標を設定し、価値をー英語そのままの意味でー人に示せるようなふるまいとして定義することが必要です。私たちは、受容できない行動を呼び出すこと、その受容できない行動を安全な方法でレポートするのはOKなのだと知らせる道を、歩かなければなりません。これは難しいことです。そして努力も必要です。暇があるとき簡単にできることではなく、組織全体とコミュニティ全体を一続きにする必要があります。私たちが歩いた道の一つは、性別に関わらず平等な賃金を保証するための体系的な変更を実施したことです。それは昨年のことでしたが今後も続けます。PagerDutyでは、男性と女性のチームメンバーは、仕事により1〜2%の範囲内で、均等に報酬を受けています。

私たちは私たちのインクルーシブな企業文化を非常に誇りに思っています。それは当初から、私たちのビジネスの中心的な教義と資産となってきました。 最高経営責任者(CEO)として、私と私たちのリーダーシップチームは、全力で私たちの価値を実証する過程では、思慮深く、意識的に、そして目に見えることが重要だと分かっています。 我々の価値観は、ポスターに書いた言葉以上のものであり、一緒に勝つ方法、コミュニティの倫理、完全性、平等、インスピレーションのタペストリーのファブリックを定義しています。

Community。 PagerDutyはすべての人のためのものです。 Trust。 私たちを信頼じても大丈夫です。私たちができると言ったことは絶対成功させます。 Growth。 私たちはユーザーと顧客のために、私たち自身の個人的な発展のために、そしてビジネスの中で、不屈の精神と立ち直る力と集中をもって、成長するために努力しています。 Passion。 私たちは一体です。あなたがしていること、それをしてあげている誰かを愛することに喜びがあります。 Team。 私たちは一つの多様性のあるチーム(ONE DIVERSE TEAM)です。 我々は一緒に勝ち、失敗し、一緒に学びます。

私たちは、他の企業やチームが、私たちの学びを活用して、自分たちのチームの中でのインクルージョンを促すことを期待をして、3つのイニシアチブを共有しています。

  1. 財団の設立:新しい従業員リソースグループとリーダーシップ開発

従業員リソースグループ(ERG:Employee Resource Groups)は、組織の使命、価値観、目標に合わせた多様で包括的な職場文化を育成する、自発的で従業員主導のグループに資金提供しています。私たちは最近、PagerDutyで次の5つのERGを立ち上げました。

SisterDuty。女性のための包括的な文化と専門の開発の機会を促進する。 RainbowDuty。性別または性的志向にかかわらず、すべての従業員にとって積極的で協力的で包括的な環境を促進すること。 PatriotDuty。募集、社内教育、地域社会への取り組みを通じた軍事的支援とプレゼンスを促進し構築すること。 Migrant Duty。理由にかかわらず、生まれた国では働いていない海外からの従業員をサポートする。 Array。多様で包括的なグローバルな職場環境を整え、奨励することにより、黒人/ラテン系の従業員のための働く場を当たり前のものにすること。

これらのグループは、ワークフォースの中でも伝統的に少数派の従業員を受け入れ、職場のネットワーク、擁護者、そしてメンターの支援を組織化して提供します。ロールアウトして以来PagerDutyの草の根組織であるERGは、すでにさまざまなメンター・ネットワークを作り、Pride Week(プライド・ウィーク)の間にお祝いのブランチを開催するなど、素晴らしい仕事をしています。

さらに、当社の疲れを知らないマネージャーたちは、すべての従業員が限界まで激しく働けて、繁栄し、成長し、変革することができる適切な作業環境を構築するために非常に集中しています。次世代の業界リーダーを育成し準備することは、私たちの責任だと考えています。そのため、彼らに世界の変化のペースについていけるだけの基礎的なリーダーシップスキルと知識を身につけさせなければなりません。

さらにチームを成功に導くため、新しいリーダーシップ、マネージャー、インタビュアートレーニングプログラムを開始し、差異の受け入れと活用に特化したモジュールを追加しました。また、日々の管理やインタビューの過程での多様性やインクルージョンに関する具体的な行動項目を設定しました。

2.多様性を人材募集の優先事項とする

昨年(訳注:2017年)だけでも、当社はオーストラリアと英国にオフィスを開設し、ワークフォースも大幅な成長を見ました。PagerDutyは、Inc 500によって最も成長が著しい会社に選ばれ、2016年と2017年の両方でForbes Cloud 100とDeloitte Fast 500リストに追加されました。

高度な成長は驚異的な才能の必要性をさらに増幅します。新しい人を連れてくる際には多様性に焦点を当てなければ、針を動かすことはできません。だから私たちは自分のバージョンのNFL ルーニー・ルール(Rooney Rule) を公​​開しました。仕事が投稿された瞬間から多様なパイプラインを提供することに重点を置いています。 最終回のインタビューで不十分な人口からの候補者を見たことがない場合は、単にオファーを延長しません。

(訳注:ルーニー・ルールとは、「NFLのチームのヘッドコーチやゼネラルマネジャーを募集する際には、最低1名はマイノリティグループ(黒人若しくは少数派民族等)の候補者を面接しなければならない」というルールのこと。これを考案(制定は2003年)したピッツバーグ・スティーラーズ会長で、リーグのダイバーシティ委員会議長だったダン・ルーニー氏の名にちなむ。)

私たちはまた、インターンシッププログラムで独自のアプローチを取ってきました。大学キャンパス採用プログラムとの素晴らしいパートナーシップに加えて、私たちは複数のパートナーシップとハッカソンを活用して、少数派の人に手を差し伸べることに重点を置いています。自分たちの努力のおかげで、私たちのエンジニアリングチームは過去12ヶ月間にインターンの数を3倍にできたことには私も感動しました。昨年開催したインターンシップのクラスは、50%の女性/黒人/ラテン系の人で構成されていました。今夏は、Code2040から最初の仲間たちを迎えつつあり、新鮮で多様な才能を私たちの早期キャリアプログラムに迎えるさまざまな方法を引き続き検討する予定です。

  1. BabyDuty:新しい親をサポートする、業界をリードする育児休業ポリシー

米国の親は、仕事と家族のバランスを取ることになると、苦しい戦いに直面します。 米国では、育児問題に結びついた生産性の低下や欠勤により、ビジネス界は 毎年44億ドルの損失を抱えています。 経済協力開発機構(OECD) によると、米国は有給育児休暇を国で義務付けていないことで、41カ国の先進国の中で最下位のランクとなっています。 国として、私たちは子育てをする親達のキャリアの成長を可能にする必要があります。

PagerDutyは、この重要な動きを支えるために私たちの資金を投入することを優先するようにしました。 当社の新しい育児休暇に関するポリシーは、業界で最も寛大なものの1つです。業界平均の13-14週間と比較して、当社では米国の有給父母休暇手当を雇用保証付きで22週間に設定しています。養子縁組の親を含む、妊娠していない親に対して12週間の有給育児休暇を提供します。 私たちは、BabyDutyのチームメンバー全員が、育児に必要な休暇をを取り新しい子供と過ごすことが可能になったことを非常に誇りに思っています。

最近のマッキンゼーの調査によると、「人種や民族の多様性に関して上位4分の1にある企業は、財務収益率で各国の業界中央値を上回る確率が35%」とされています。PagerDutyでは、初期から多様で包括的な企業文化を実践しています。 チームに力を与え、企業文化を強化し、具体的なビジネス成果を生み出す方法を直接見てきました。 CEOとして、私は活気のある企業文化のこの主要な柱となる部分に個人的に献身しており、これを次のレベルに上げるために引き続き取り組むことを楽しみにしています。

さらなる背景については、国際女性の日のために私たちのチームに送った私のメッセージをご覧ください。 ハッピー・ウィメンズ・デイと、私の家とも言えるこの素敵な会社(PagerDuty)をリードするため最高のバージョンの私を見つけてくれた素晴らしい女性と男性たち(あなたたちは誰かわかっていると思います)に感謝します。

ハッピーインターナショナル・ウィメンズ・デイ! 今夜私は仕事から少し遅れて帰ってきました。私たちの12歳のサマンサと私はキッチンに一緒に立っていて、夫が親切にも買ってきてくれたテイクアウトのフォーを食べていました。私たちはミシガン州に住む甥に午前12時に誕生日のお祝いのメッセージを送り、明日のプレー・プラクティスのためにカープールを予約していないことに気付きました。月曜日までに英国のプロジェクトがあります。これは明らかに珍しいアートのサプライが必要でしたし、出張旅行のために私が欠席する学生主導の会議を再スケジュールするためにサムの教師に電子メールを送る必要があります。私の夫はオーストラリアのクライアントとの電話会議で2階にいました。サムはすっかり心得ていました。彼女はGoogleの International Women’s Day doodle (国際女性デーのドーダリー) のほうに興味を持っていました(クール、でしょう?)。

Norman Rockwellの家族の夕食の肖像画そのままというわけではありません。しかし、それは私たちの “普通の”ことです。私たちは何年もの間、私たちのクレージーなスケジュールに適応して、こんな風に夕食を「一緒に」食べて、同じ町の中に一緒にいるこういう単純な瞬間の連続をかけがえないものだと分かっています。私は仕事が大好きで、個人の人生も大好きで、ある時はこんな風に同じ日に両方を全てうまくこなせるのです。

夕食のあいだ、サムと私はまた、International Women’s Dayを祝うための計画について話し合いました。その日私は紫色のドレスを着て、彼女は髪に紫色のシュシュを着けることにしました。ドーナツも持っていきます。サムは学校で「米国の女性は平均で男性より1ドルあたり17セント給料が安い」という新しい情報を学びました。でも私は彼女にPagerDutyではそうでないことを伝えられて誇りに思っています。job-for-jobに、私たちは昨年1〜2%の範囲内のジェンダー・エクイティを達成しました。

彼女はパリティを達成するために一所懸命働かなければならないことを「狂った町」だと考えています。これは私に希望と喜びをもたらします。彼女と次世代の起業家と指導者が今日出現した行動主義と対話から学び、より包括的で公平な文化、企業、チームを設計することを願っています。実用主義的で、オープンマインド、そして好奇心の強い十代の若者時代を通して、効果的に先に進む機会を半分得ている自己実現性の高い若い女性に育っていることを知るのは嬉しいことです。彼女は、私たちが今日経験しているよりもさらに、職場において平等が進む機会に会えるでしょう。

2018年国際女性デーのテーマは、 #PressforProgressです。PressforProgressは、賃金の平等のような測定可能な進歩に重点を置いて、すべての人々の平等と社会正義をサポートするために、女性の同僚、チームメート、友人や家族に寄り添う行動をしようという呼びかけです。ジェンダーによるペイ・ギャップをなくすことはよい起点ですし、私たちはPagerDutyの進歩を祝うべきだと考えます。私たちは業界を実例でリードしているのです。私たちは、リーダーシップの役割を担ってジェンダー・エクイティに向かって進んでおり、最近は、エンジニアリングのリーダーシップでジェンダーバランスを達成しています。そして表面に現れない少数派のインクルージョンを進めダイバーシティのゴールに向かって進んでいます。私たちがやるべき仕事はもっとたくさんあります。

ハイテク産業と米国は、バランスのとれた平等を達成するために、他の産業や国の後塵を拝している恥ずべき存在です。我々が良いもののために革新し、現状を打破し、世界を変えたい場合、より多くの進歩を早める必要があります。私は個人的にこの挑戦の端緒を作ると約束しており、私はあなたの助けが必要です。私は頻繁に「どうすることができますか」、あるいは「どのように助けてくれるのですか?」と尋ねられます。私の好きな提案は次のとおりです。

あなたのようではない人に、職場で目標を達成するためにできることを尋ねてください。対話を開始して聞いてください。#empathy 当社の社内外で女性または少数派の人を後援すること。これは、あなたのネットワークへの紹介をしたり、誰かをオープンな役割、昇進、または賞賛のために推薦する機会(話し合い、ネットワーキングイベント、名高いプロジェクト)に招待するなどの単純なことでできます。 部署やチーム、プロジェクトにバランスをとる機会がある場合は、掛け声をかけて他の人を招待してください。計画を立て、次の会議に先立って不公平に対処してください。 他者を助け、包括的な行動を奨励し、実証し、部署の声をシェアして、声なき人の声を増幅したり励ましたりすること。 善意を持とうとすること。私たちは不完全な人間です。私たちは間違いを犯すでしょう。私たちは一緒に強くなれます。あなたに似ていない人と単独で会うことを恐れないでください。恐れは軽視を生みます。

団結を示すために紫色を着用する 紫色のリボンのSlack emoji (:iwd:) を使用してください #PressforProcess selfieカードで画像を撮り、#sisterdutyチャンネルに投稿してください

サンフランシスコとトロントのオフィスでイベントを企画してくれたSisterDutyに感謝します。 Discussion Panel at 9 am PT / 12 pm ET featuring four local women professionals

Roula Vrsic – Agreement ExpressのCMO Cinzia Bazzo – SalesforceのStrategic Account Executive, Canada Enterprise Cheri Mara – Indigo Booksのデジタルマーチャンダイジング担当VP Kelly Festarini – Procter & GambleのCustomer Business Development New Hire Capability and Recruiting担当

#YouToo: Feminism, Activism, and Allyship at 12:15 pm PT / 3:15 pm ET 当社のRenee Lungは、肯定的な変化の一部となる方法と、#metooが何を意味し、それを#youtooに変更することは何を意味するかを話します。 最後に、地域社会の女性を支援するスポンサー、同盟者、そしてメンターに感謝します。 ハッピーレディースデイ! Jenn

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

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

オペレーションの未熟さがコストを増大させる

Aditya Patil

January 3, 2019

デジタル運用の成熟度とは?

デジタル運用の成熟度は、リアルタイムの作業での組織の有効性と、その組織がインシデントへの対応に熟達するにつれて改善するパフォーマンス指標にフォーカスする能力として、定義されます。

PagerDutyは、複数の業界に渡る600名以上の回答者を対象にした調査を含む、広範囲な調査と9年間の業界のデータに基づいて、次の4つの運用成熟度レベルを特定するモデルを開発しました。

リアクティブな組織は、ほとんどの問題を顧客が報告したときに見つけることが多く、これらの問題に対処するためのプロセスを持っていません。第1線にいるレスポンダーが、サービスの問題を解決するためのスキル、知識、または権限を持っていないこともよくあります。 レスポンシブな組織は、顧客に影響が出る前にいくつかの問題に直面します。第一線のレスポンダーはスキルを持っていて問題を防ぐための権限を得始めています。しかし、その人々はまだ自分たちの仕事をするのに必要な情報を欠いています。 プロアクティブな組織は、顧客が影響を受けたり気付いたりする前に、ほとんどの問題をあぶり出して解決します。過去の問題から学んだことは自動的に文書化され、レスポンダーは現在の問題を解決し将来の問題を防ぐための知識と権限を与えられています。 プリベンティーティブな組織は、顧客に影響が及ぶ前に、ほとんどすべての問題をあぶり出して解決します。このレベルを達成するのは非常に困難であり、このレベルで活動している組織の特徴は継続的に学習する文化を持っていることです。この組織のレスポンダーは、現在の問題を解決し将来の問題を防ぐための知識と権限を十分に与えられています。これらの組織は、リアルタイムの対応プロセス全体にわたって自動化の仕組みを多用しています。

PagerDutyは、以下の図に示すように、組織の運用上の成熟度を決定する上で重要な5つの重点分野を特定しました。

5つの重点分野がビジネスの改善にどのように役立つかについて、さらに詳しく説明しましょう。

1.カスタマーエクスペリエンスを改善する

ビジネスを常に「顧客第一」と考えるように位置付けることは、今日の市場では重要です。これは、顧客にシームレスで中断のない経験を提供するために可能な限りのことを行うことを意味します。次のシナリオを検討してください。

あなたはサンフランシスコのサウス・オブ・マーケット地区にあるお気に入りのPhilz Coffeeに来て、ブリトーを欲しがっています。あなたは自分のスマホでライドシェア用のアプリAを開きますが、それがロードされません。それであなたは数秒待ちます。いや、まだロードされません。ついにあなたはあきらめてアプリを閉じて、競合他社のアプリBを開きます。これでは、Aの売り上げを失ったことになりますね。それだけじゃありません。

次回乗車が必要になったときには、前回のライドシェア会社Aでの体験を覚えている可能性があるので、まずB社のアプリを開きます。つまりそうした1つのちょっとした体験がA社の評判を損ない、将来的に売り上げをフイにさせる可能性があります。実際、Gartnerは、平均的な企業のダウンタイムコストは1分あたり5,600ドル、または1時間あたり約300,000ドルであると見積もっています。

潜在的なお金を失う可能性は大きいのです。顧客と収益を維持するために、企業は自社のデジタルビジネスがほぼ100%常に稼働している状態を確保する必要があります。しかし、当社の調査によると、回答者の50%以上が自社の組織がレスポンシブまたはリアクティブであり、顧客に損失を与え顧客との関係を壊すことにつながるダウンタイムを防止または削減するための適切な対策を講じていないことを示しています。

  1. 従業員の健康と会社の文化を改善する

最も単純に言えば、企業は共通の目標に向かって努力する人間の集団に他なりません。 (そしてPagerDutyには最高の人間がいます。一緒にやりましょう!)

従業員は会社の最も貴重な資産でもあるので、燃え尽きを防ぐための対策を講じることはその人たちの幸せと生産性を維持するために不可欠で、結果的に離職率も低くなります。

なぜ組織が離職率を気にする必要があるのでしょう?貴重な蓄積された組織知を失うことは置いておいて、IT専門家に関するPagerDutyの最新の調査では、1人の経験を積んだレスポンダーを別の人に変えるには最大30万ドルものコストがかかることが分かりました。こうした種類の数字を検討すると、次のような質問をすることによって個人と全社の健康状態を追跡することが会社にとって最も重要です。

勤務時間後に従業員が呼ばれる頻度はどのくらいですか? あなたのチームのIT担当者の年間離職率はどのくらいですか?

これらの指標にアクセスできることは有益で、対処不可能なアラートや繰り返し発生する対処不可能な量のインシデントが、仕事から離れた従業員をイライラさせることにつながることを理解できるようになります。また、アラートの数を減らすことによる影響はすぐには表に出ないものの、時間の経過とともに大きな違いが生じることも当社のデータから明らかになっています。

現実に、アラートを減らすための対策を講じた成熟した組織では、成熟していない同業者と比較して、オンコールする担当者(レスポンダー)の離職率が21%低くなっています。 50人のレスポンダーがいて、10%の離職率である会社の場合は、21%の削減は年間31万5000ドルの節約になります。

  1. MTTRを削減するために各プロセスを最適化する

プロセスの最適化は組織がスケールするにつれて重要になります。しかし、それは単にベストプラクティスを見つけてそれに従えばよいというわけではありません。つまり、各企業は改善のための領域を特定するために既存のプロセスを評価する必要もあるのです。 例えば、インシデント対応中の利害関係者への通知は、ほとんどの組織で改善できるプロセスです。以前のブログで説明したように、中核の対応チームの外にいる人々に最新情報を提供するためのコミュニケーション戦略を構築することで、オンコールレスポンダーはインシデントの解決にもっと時間を費やすことができます。

さらに、インシデント対応プロセスは、インシデントが解決されたというだけでは完了しません。成熟した企業におけるデジタルオペレーションの要素には、チームが根本原因の分析を実行できるようにする、ブレームレスつまり個人の責任を問わない事後分析(ポストモーティム)プロセスが含まれます。これはパターンを解析し、類似のインシデントが再発するのを防ぐのに役立つ洞察を提供します。

  1. 知識共有の実践を育てる

  2. 正しい技術とツールを使う重要性

現代では組織がビジネスプロセスを最適化するのを支援するために豊富な技術とツールが利用できます。そして健全で成熟したデジタル運用のプラクティスを構築する場合でも同じです。オンコール中の従業員は、大量の通知や対処できない警告に溺れてはいけません。以下の表は、組織の成熟度に3つの重要な指標がどう対応しているかということに関するいくつかの重要な発見をまとめたものです。

注目すべき点は:

最も成熟した回答者は25%のアラートしか 対応不能(unactionable)なものはないと回答していますが、最も成熟していない回答者は28%のアラートがunactionableだったと回答しています。 最も成熟した回答者のインシデント対アラート比(incident-to-alert ratio。実際にインシデントになったアラートと全アラートの比 )は約1:3でしたが、最も成熟していない回答者は約1:1でした。 最も成熟した回答者は自動化で問題の57%を解決しました**が、最も成熟していない回答者は自動化で問題の16%しか解決できませんでした。

成熟した組織によくある最も一般的な特徴は、過去のインシデントから学んで、それによって、顧客が影響を受けるようになる前にインシデントを解決する、またはアラートのノイズを減らす、どちらかのテクノロジーを利用していることです。 従業員が対応不能なアラートの確認と自動化で解決される可能性のあるインシデントの手動での解決に注力している場合は、て本来は業務の革新や他の問題解決にかけるべき数えられないほどの人・時が失われます。重要なのは、組織のデジタル 運用をReactiveからPreventativeに成長させ、そしてカスタマーエクスペリエンスを向上させるための革新の推進に集中するために、チームに適したツールを見つけることです。

組織の運用上の成熟度を向上させる方法についてもっと知りたい場合は、弊社までぜひお問い合わせください。

GET STARTED

この記事は、PagerDutyサイトに掲載されたブログをDigitalStacksが和訳・追記したものです。無断複製を禁じます。原文はこちらにあります。

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

コンピューターの使い方:最先端のインフラストラクチャーの様相はどう変わったか

今日のインフラストラクチャ はあなたの祖父母の時代のITインフラではなく、1世代前のインフラでもありません。 パンチカード、真空管、フェライトコアメモリー、フロッピー、ダイヤルアップインターネットの時代はもう終わりました。

そして今日のインフラは、5年前、あるいは1年前のITインフラでもありません。 現代のインフラは絶えず変化しています。この記事で私たちにできるのは、インフラのスナップショットを見せ、それが今度どうなるのかという一般的なイメージを伝えることです。

インフラの効果的な監視には、今日のインフラの様相とそれがどう変わっていくか、将来何がそこに含まれることになるのかを理解しておく必要があります。

ハードウェア:たぶんムーアの法則の予想を下回る

ハードウェアインフラは比較的安定しており(「相対的に」という言葉が強調されています)、数年間は半安定の状態にあります。 ムーアの法則が限界に達しつつあるという推測は時期尚早ですが、Mooreの法則が描く曲線は、少なくともプロセッサ速度とRAM容量(大容量ストレージは別の話かもしれない)に関しては、部分的に平準化しつつあるようです。

ソフトウェア:変化するのが自然

この平準化は、ITインフラの最も重要な変化がソフトウェア側で起きていることを意味します。これは驚くべきことではありません。なぜなら、現代のインフラはかなりの部分をソフトウェアに負っているからです。 SDN(Software-defined networking)、仮想マシン、コンテナなどは、今日のハードウェアとソフトウェアの間の線が事実上ひどくあいまいになっていることを示しています。

ソフトウェアとしてのITインフラが現代のコンピューティングの大事な要素だということは驚くべきことではありません。 結局のところ、ハードウェアは基本的にフレームワークであり、何かを可能にするために設計された構造です。 その可能性を利用できる人は、世界にあらゆる違いを生み出すことができます。

ハードウェアの遅れから解放される

ソフトウェアベースのインフラへの移行は、これまでのプラットフォームの変化をはるかに超えた意味を持ちます。一つは、ハードウェア自体の変更の速度に大きな遅れが見られることです。物理サーバー、ネットワーク、および周辺機器を交換またはアップグレードするには、費用がかかり、時間がかかるので。その必要性が明確になるまで(またはなった後まで)、多くの組織が長い時間待って、それからハードを更新していました。この遅れはほんの数年かもしれませんが、レガシーなハードウェアとそれに必要なレガシーなソフトウェアの両方を共存させることを要件としたために、ソフトウェアレベルにもインフラのハードウェア自体にも影響を与えました。

しかし、現代のソフトウェアベースのインフラでは、アプリケーションソフトウェアとインフラを構成する要素の両方が、基本的なハードウェア要素の大部分(全てではないにしても)から隔離されています。ハードウェアが抽象化レイヤーの要件をサポートできる限り、インフラ自体にはハードウェアの遅れの影響がほとんどありません。

「ソフト」要因

結果として、インフラソフトウェアとアプリケーションソフトウェアの両方の変化の速度は、現在の組織文化やソフトウェア設計と開発の速度に関する現実の制限などの他の要因に支配されています。 これらの要因は一般的に「ソフト」的であり、それが課す遅れははるかに短く、特定の組織内の一般的な状況により多く依存しするようになっています。

今日のインフラ

つまり、今のコンピューティングへの理解は、現代のITインフラの現状を今のこの時点でとらえたスナップショットに過ぎないことを意味します。 そのようなスナップショットには何が含まれているでしょうか? 大事な要素は次のようになります。

クラウド。インフラが抽象化された複数の層の上に位置するソフトウェアである場合は、それが特定のサーバーまたはネットワークのセットに結び付けられる理由はありません。 クラウド(基本的に高レベルの抽象化レイヤー)は、開発者が相互作用する最も基本的なインフラになります。 開発者が作成し管理するインフラは、それがVM上で実行されているアプリケーションであっても、仮想化されたホストシステム上で実行されているコンテナで構成されているものであっても、実質的に完全に仮想化されています。 仮想化。 仮想化は既存のものとなっていて、私たちは今この事実の意味を理解し始めているだけです。 既存のオペレーティングシステムはもともとハードウェアによって課せられた制約を念頭に設計されていました。 ハードウェアに課せられた制限を参照することなく完全に設計されたシステムはまだありません。

しかし、現在のオペレーティングシステムの限界があっても、標準となった仮想化を使えば、アプリケーションだけでなく、それらが存在する環境も、伝統的なOSで実行された簡単なプロセスと同じくらい簡単に、作成、管理、 破壊できます。

パイプライン全体の自動化** インフラがソフトウェアの場合、他の種類のソフトウェアを管理するのと同じ方法で、インフラを管理するのが合理的です。 また、この自動化をソフトウェア配信パイプライン全体にわたって拡張することも合理的です。それがパイプラインの全プロセスを管理するための単一のシステムの形を取ったとしても、あるいは必要に応じてタスクを互いに引き離す一連のスクリプトの形になったとしてもです。

伝統的に、自動化はしばしばスケジュール駆動型でした。 しかし、現代のインフラストラクチャーでは、通常、イベント駆動型です。 これにより、より大きな柔軟性が得られ、不要な遅延が排除されます。

切れ目のない配送**。 そういうフレキシブルな応答駆動型の自動化は、当然、継続的な配信につながります。 手作業による介入や配送プロセスによる遅れがないのですから、連続してはならない理由はありません。

実際、配信が途切れ途切れになっていた理由は、通常、仮想化されていないインフラと配信パイプラインが自動化されていなかったからです。 仮想化されたソフトウェアベースのインフラを完全に自動化する機能と組み合わせることで、ハードウェアベースのインフラの制約に対応する必要性がなくなり、継続的な配信が可能になりました。インシデント管理で継続的な配信を最適化する方法については、こちらをクリックしてください。

https://www.pagerduty.com/resources/learn/continuous-delivery

では、今日私たちはどうにコンピュートするのでしょうか? 私たちは仮想化され、抽象化の複数のレイヤーによってハードウェアレベルから隔離された環境でコンピュートしています。 当社の開発およびデプロイメントパイプラインは、イベント駆動型の自動化によって途切れることなく管理されています。 多くの点で、現代のIT環境は、従来のハードウェアベースのIT世界から隔離された仮想世界になっており、数年前にITを支配していた懸案の多くが無関係になっています。

バーチャルな明日?

以上が今日のスナップショットだとすれば、明日は、さらに5年先、10年先はどうなるのでしょうか? もちろん、実際に知る方法はありません。今日の予測は、時間が経つにつれ、だんだんと的外れになる可能性があります。

しかし、ここにいくつかの他の予測があります。ハードウェアによって課せられた制約から仮想コンピューティング環境を解放する効果が見え始めたことがその1つにあげられます。また、仮想化されたコンピューティングと、バーチャルリアリティと、昔からの物理的な経験の区別が崩壊する可能性があります。多くの点で、今日のコンピューティングの変化の速度は、私たちの能力によって制限されています。つまり変化が発生したときにそれを私たちが吸収し、発達するにつれてその力をフルに活用する能力によって制限されています。しかし、自動化とインテリジェンス機能は、垂直でもドメインでもほぼ全ての機能を破壊的に変え、効率性の新たな可能性を広げ、人々の作業の焦点を劇的に変える可能性があります。

おそらくコンピューティングと日々の経験の両方の仮想化は、将来の変化を吸収する速度を早めます。私たちが未来のクリエーターになり、未来に参加する可能性が高いとしても、このような場合、もし今私たちがその一部を垣間見られたとしても、将来のコンピューティングと人間生活の両方が完全に理解不能になります。世界を変えるなら私たち自身も変えることになるのです。

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

インシデント発生時のベストなコミュニケーションの方法

あらゆるビジネスが デジタルビジネス に進化し、ほんの少しの停止時間でも、これまで以上に収益とブランド価値に深刻な影響を与えるようになり、危機に直面した際の効果的なコミュニケーションの必要性が増してきました。これによりサービスを開発・管理する技術チームにより高いプレッシャーがかかっているということですが、さらにデジタルトランスフォームは、ブランドの評判と顧客体験に責任を持つ他の事業部門にもプレッシャーをかけています。

製品やサービスから顧客が最大の価値を引き出せるようにする責任を負うコミュニケーション、マーケティング、とりわけサポートチームを見てみましょう。プレッシャーによって渉外機能に新しいワークフローとベストプラクティスが必要になっています。PagerDutyで私たちが学んだ実践から、これまでに磨いてきた4つのベストプラクティスを紹介します。

  1. みんながオンコール担当

PagerDutyのコミュニケーションチームの一員として、私は技術担当の同僚や他の多くの人と一緒にオンコールの仕事に従事しています。受け取るインシデント通知のほんの一部を見ても、なぜ自動化とインシデント対応プロセスを持つことがスムースな運用に必要なのかを深く理解しています。それが今日のデジタルサービスをうまく稼働させているのです。何かが顧客にインパクトを与えるとき、コミュニケーションチームやサポート、営業、法務、そしてリーダーなど他の部門の関係者は、私たちが顧客と適切なコミュニケーション対応をプロアクティブに取れること、そして時が経つ間に自らのブランドと顧客の約束を守るために正しい対応を効果的にやれるのだということを、知っておく必要があります。

2.サポートと足並みをそろえる

受賞経験のある当社のサポートチームは重大インシデントに遭遇したときには顧客対応の最前線に立ちます。しかしコミュニケーションチームは次のことを理解するために整列して待機しています。

どんなインシデントでなぜそれが起きたのか? どのくらい多くの顧客がどのくらい長く影響を受けているのか? インシデント対応はどのくらい進んでいるのか(まだ調査中なのか解決に近づいているのか)?

インシデント対応プロセスの中では、チームは顧客との連絡窓口(注:カスタマーリエゾン)を必要とします。その窓口担当は、アプリやサービスに起きている障害がさらに悪くなりそうな時に外部と最善の方法でコミュニケーションをとれるよう訓練されている人たちです。

私たちのコミュニケーションチームは、今何が起きていてどんな影響があるのかを正確に理解するために、カスタマーリエゾンと一緒に作業をします。PagerDutyの中では、インシデントに関するSlackチャネルの一部に加え、Stakeholder Engagementという機能で情報の更新を自動化しています。我々は各チームからより抜かれた適切な人の間で協業が進むようタイトなラインを作り、顧客やより広い市場との有益なコミュニケーションが作れるように協力しています。

3.プロアクティブになろう

伝統的なチケットやITSMのワークフローを使っている場合、プロアクティブになる機会を失っているかもしれません。顧客は何か悪いことが起きるのをあなたより前に知ります。例えばソーシャルメディアなどの公開の場やニュースで彼らが気づく前にあなたが問題を修復する機会はないでしょう。コミュニケーション対応の観点からは、外向けに出すメッセージをより早く作れるよう行動するべきです。そうすれば不満のツイートや正しい情報を求める記者からの電話に対応できるようになります。インシデント対応コミュニケーションのこの段階では、傷ついた評判を修復する戦略を立てることが大事であり、理想的には事態を正常化するためにリアルタイムに起きていることを共有すべきです。プロアクティブなコミュニケーションを支援するため、我々は発生しうる危機のシナリオを特定してワークフローを作り、さらにこれまでの経験に基づいて、使うべき言葉を中心に、ベストプラクティスを作成しました。もちろん、危機シナリオは独自のものですが、平和な時に基礎を作っておけば、余裕がなくとストレスが高い戦闘中でも、素早く行動できます。

4.ブランドをリシェイプする

インシデントが解決してもコミュニケーションチームの仕事は終わりません。理想的なインシデント管理のライフサイクルの中で、重大インシデントは必ず事後検証を受けるのです。その中では関係者全員が、何が起こったのか、その対応がどう実行されたのか、今後どのように改善できるのかを議論します。これは学習と改善のための時間です。コミュニケーションチームにとしては、組織全体で協力し顧客や広範なコミュニティの信頼を回復する計画を策定し実行する必要があります。つまり当社のブランドが期待に応えられなかった部分を改善する戦略を実行するのだと考えてもらってよいでしょう。企業としての表明も改訂し、健全な判断を使い今後どうするのかを検討しないといけないでしょう。これはまた、あなたががビジネスに携わっている理由と言行一致を確約するための時間でもあります。ビジネス全体での行動が間違いを正すために必要かもしれません。

今日の、”マイクロ秒単位の時間”に支配され、常時オンが当たり前の世界で成功するためには、コミュニケーションチームは他のチームと一緒にデジタルオペレーションのエクセレンスの追及に”レーザーフォーカス”しなければなりません。これは、これまでと違う覚醒を意味するだけでなく、法外に優れた顧客体験を提供することを心の中の統一目標として、各機能部門を横串した新しい作業とコラボレーションのやり方を意味します。

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

DevOpsの効率を上げるため適切なツールを選択する

運用面での成熟は、いくつかの新しい ツール を実装したからといって一晩で起こるものではありません。核となるのは、より良いソフトウェアを提供するためみんながコミュニケーションのサイロを壊せるよう一丸となって文化を変える努力です。個別にツールがあるだけでは十分ではありませんが、スピードと精度を向上させ、コラボレーションを促進するようなオートメーションを適用すれば、ツールが大きな利益をもたらすようになります。

環境に合ったDevOpsツールは、チームの規模やニーズに応じて大きく異なる場合があります。あなたのツールチェーンを構築する方法には正解はありません。現実に、まず私たちが学び、模倣しようとしたいくつかの最良のワークフローやツールはNetflix、Etsy、Dropboxなどの革新的なチームが社内に構築したものだということを告白しておきましょう。

このリストの目的は、ソフトウェア配信ライフサイクルの各段階で最も人気のあるツールをいくつか共有することです。その一部は社内でも使っています。自分のチームのために適切なツールを評価する際にご参考になることを願っています。

計画

何をどうビルドするのか

リリースのすべての単一の依存関係と作業を計画しておくというウォーターフォール型のアプローチはDevOpsに反します。代わりに、アジャイルアプローチでは、ソフトウェアを小さな塊で構築してテストし、顧客のフィードバックを反復することで、リスクを減らし、可視性を向上させることができます。それが私たちを含む多くのチームが約2〜4週間のスプリントでの私たちがリリースを繰り返している理由です。

チームが各スプリントの開始時にアイデアや計画を共有しているので、以前のスプリントの反省からのフィードバックを考慮に入れてチームとサービスが継続的に改善されるようにします。ツールは学習やアイデアを計画に集中させるのに役立ちます。ブレーンストーミングプロセスを開始する際は、顧客リサーチデータ、機能要求、およびバグレポートをそれぞれ対象となる個人を特定し、その人にマップできます。このプロセスでは、物理的またはデジタルの付箋を使用して、共通のテーマをまとめてグループ化し、バックログのユーザーストーリーを構築しやすくします。ユーザーストーリーを特定のペルソナにマッピングすることで、提供される顧客価値に重点を置くことができます。アイデア段階の後、プロジェクトのバーンダウンと毎日のスプリントの進行状況を追跡するツール内のタスクを整理し、優先順位を付けます。

私たちが使っているツール:Active Collab、Pivo​​tal Tracker、VersionOne、Jira、Trello、StoriesOnBoardなど。

コード

いくつかのコードを書いた後に、ステージングに入る前に済ませる必要があることがいくつかあります。 コードをレビューして承認し、バージョンコントロールリポジトリのマスターブランチにマージし、必要に応じてローカルテストを実行します。

トップツール:Github、Bitbucket、Gerrit、GitLab

テストとビルド

今度はコードのビルド、テスト、およびリリースに関連するタスクの実行を自動化する時です。 ビルドが展開される前に、単体テスト、統合テスト、機能テスト、受入れテストなど、生産過程に完璧に押し込めることを確認するために、多数のテストを行う必要があります。 テストは、新しい変更が導入されたときに、コードベースの既存の部分が期待どおり確実に機能し続けるようにするための素晴らしい方法です。 新しいプルリクエストがあるときには自動的にテストを実行することが重要です。 これにより、手動による監視のために見落とされるエラーを最小限に抑え、信頼性の高いテストを実行するコストを削減し、早期にバグを面に出せます。

また、テストが完了したら、マスターの変更を自動的にピックアップし、依存関係のあるものをリポジトリからプルダウンして新しいパッケージを構築するなど、便利な機能を果たす多数の優れたオープンソースツールと有償ツールもあります。

トップツール:Jenkins、GoCD、Maven、CruiseControl、TravisCI、CircleCI

コンテナとスケジューラ

Dockerとコンテナの登場により、チームは新しい仮想化オペレーティングシステムをスピンアップすることなく、軽量で一貫した使い捨てのステージング&開発環境を簡単にプロビジョニングできます。

コンテナは、アプリケーションをパッケージ化する方法を標準化し、記憶容量と柔軟性を向上させ、変更をより簡単にすることを容易にします。 これにより、アプリケーションをどこでも実行することができます。 言い換えれば、物事は、あなたがラップトップで変更を加えたときとまったく同じように、魔法のようにプロダクションで行動します。

トップツール:Docker、Kubernetes、Mesos、Nomad

構成管理

構成管理を使用すると、インフラストラクチャの変更を追跡し、システム構成の単一ソースを維持できます。 バージョン管理とイメージの複製を簡単に実行できるツール、つまりシステム、クラウドインスタンス、コンテナなどのスナップショットを撮ることができるツールを探してください。 ここでの目標は、標準化された環境と一貫した製品パフォーマンスを保証することです。 構成管理は、変更に起因する問題の識別にも役立ち、さらに容量が必要な場合に既存のサーバーを自動的に再現することでオートスケーリングをシンプルにします。

トップツール:Chef、Ansible、Puppet、SaltStack

リリース リリースの自動化

リリース自動化ツールを使用すると、本番環境に自動的にデプロイできます。 自動ロールバック、展開を開始する前にホストに成果物をコピーする機能などを備えた製品を選ぶべきであり、特に大規模な組織の場合は、サーバーインスタンスのスケールに合わせて、エージェントを簡単にインストールし、ファイアウォールを簡単に構成できるエージェントレスアーキテクチャが必要です。

テストに合格したものは、自動的にデプロイされることに注意してください。 ベストプラクティスは、最初に「カナリヤ」デプロイメントとしてインフラのサブセットに展開してみて、エラーが起きなければ全体に展開することです。

多くのチームでは、ボットを使って簡単なコマンドでデプロイするチャットベースのデプロイメントワークフローも使っているため、誰もが簡単にデプロイメントの活動を見たり、一緒に学習することができます。

トップツール:Bamboo、Puppet

デプロイメントを監視する

リリース用のダッシュボードとモニタをセットアップすると、リリースの進捗状況と要件のステータスをハイレベルで視覚化するのに役立ちます。 サービスが健全かどうか、導入前、導入中、導入後に異常があるかどうかを理解することも重要です。継続稼働している統合サーバー上で発生する重要なイベント、例えば失敗したビルドがあるとか、デプロイメントを中止またはロールバックするといった重要なイベントがリアルタイムで通知されること確認しておくことです。

トップツール:Datadog、Elastic Stack、PagerDuty

モニター サーバーの監視

サーバーの監視では、インフラストラクチャレベルのビューが提供されます。 多くのチームでは、ログの統合機能を使い特定の問題をドリルダウンしています。 このタイプの監視をすると、メトリック(メモリ、CPU、システム負荷の平均など)を統合でき、サーバーの健康状態を常に把握でき、アプリケーションが影響を受ける前に(そしてお客様がそれに気がつく前に)に問題に対処できるようになります。

トップツール:Datadog、AWS Cloudwatch、Splunk、Nagios、Pingdom、Solarwinds、Sensu

アプリケーションパフォーマンスの監視

アプリケーションパフォーマンスの監視では、Webサイトなどのアプリケーションやビジネスサービスのパフォーマンスと可用性をコードレベルで把握できます。 これにより、パフォーマンスメトリックを迅速に理解し、サービスSLAを満たすことが容易になります。

トップツール:New Relic、Dynatrace、AppDynamics

対応と学習 インシデント解決

監視ツールは豊富なデータを提供しますが、リアルタイムで問題に対して正しい行動をとることができる適切な人物にルーティングされないならそのデータは無駄になります。ダウンタイムを最小限に抑えるには、問題が検出されたときに適切な情報が通知され、トリアージおよび優先順位付けに関する明確なプロセスが確立されていることが大事で、それらによってようやく効率的なコラボレーションと解決が可能になります。

1分に数千ドルのコストがかかるようなアプリケーションとパフォーマンスの問題が起きた場合、適切な対応を調整することはしばしば非常にストレスですが、混乱することはありません。火事の最中に、連絡先の住所録を取り出して、コンファレンスブリッジに適切な人を選ぶ方法を探すのに30分も無駄にするのは望ましくありません。

PagerDutyはエンドツーエンドのインシデント対応プロセスを自動化して、主要な顧客に影響を与えるインシデントや日々の運用上の問題の解決にかける時間を削減できます。 PagerDuty社内では、エンジニアリングチーム、サポートチーム、セキュリティチーム、エグゼクティブなどみんなが、自社製品を使い、ITやビジネスの中断への対応策を調整して準備しています。柔軟性を持って私たちはオンコールのリソースを管理したり、実行不可能なものを止めたり、関連するコンテキストを統合したり、適切な人やビジネスのステークホルダーを動員したり、自社が推奨するツールと協働で対応にしたりしています。自分が戦闘中に何をどうに見たいかを簡単に設計できるとしたら、あなたももっと安心できるでしょう。

私たちが使っているツール:PagerDuty、HipChat、Slack、Conferencing tools

学び、改善する

対応が終われば、インシデントはプロセスとシステムをより弾力性を持って改善する方法を理解する重要な学習機会を提供します。 DevOpssのCAMS(文化、オートメーション、測定、共有の頭文字)の支えによって、インシデント対応とシステム性能のメトリクスを理解し、継続的な改善の目標に向けて、成功と失敗を共有するオープンな対話を促進することが重要です。

ポストモーティム(事後検証)の手順を合理化でき、解決すべき事項に関するアクション項目の優先順位付けを目的にポストモーティム分析を実行できるソリューションを探してください。あなたはきっと製品の使用状況や顧客からのフィードバックを理解するのに役立つツールを使い、ビジネス目標と顧客経験のメトリクスに関連するサービスがどのくらい成功しているか測定したいと思うでしょう。より良い製品とより幸せな顧客のために、システムと機能の両方の改善を正確に計画して優先順位を付けられるよう、すべてが次のスプリントに組み込まれるのです。

私たちが使っているツール:PagerDuty、Looker、Pendo、SurveyMonkey

繰り返しますが、ツールに投資するだけでは、モノリシックアーキテクチャーからマイクロサービスアーキテクチャに移行することはできません。また、セルフサービスのデプロイメントを1日に何回も実行できるチームは幻のままになります。 しかし、適切なツールとプロセスで新しい文化へのシフトを強化することで、ソフトウェア配信を最適化し、継続的に改善し、それを担当するすべての人の間でシームレスなコラボレーションと信頼を実現することができます。

以上を参考に、あなたのための適切なツールを探究し、見つけることに成功してほしいです!全員参加の機運を最大限に高めるために社内で使用すべきツールや、DevOpsのベストプラクティスを加速する方法について詳しく知りたい場合は、これらのリソースをご覧ください。

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

ChaosCat:PagerDutyでのフォルトインジェクションの自動化

「カオスエンジニアリング とは、本番環境の分散システム が混乱状態にさらされても耐え抜く能力を実証する実験」―カオスエンジニアリングの原則

Netflix、Dropbox、およびTwilioは、カオスエンジニアリングを実行している企業です。彼らには自社の大規模で堅牢な分散システムに自信を持つことが不可欠です。PagerDutyでは、数年間、本番環境にフォルトインジェクション(一部のサーバ、サービスを落としたり負荷をかけるなどしてシステム全体の堅牢性を確認する手法)を行ってきました。時が経つに連れインフラが成長し、私たちのカオスエンジニアリングの技術も進化しました。最近追加されたものの1つに、ChaosCatと呼ばれる自動フォルトインジェクタがあります。

バックグラウンド

当初、PagerDutyのSRE(Site Reliability Engineering)チームは、SSHを使用して各ホストでコマンドを実行するという、手動のフォルトインジェクションを行っていました。これにより、障害を正確に管理し、発生した問題をすばやく調査し、ツールへの大きな先行投資を避けることができました。これはしばらくの間うまくいっており、高ネットワーク遅延、高CPU使用率、ホストの再起動など、反復可能なカオス攻撃のライブラリを構築することができました。

私たちは手作業で行っていてはスケールしないと分かっていたので、時間の経過とともにプロセスの一部を自動化し始めました。まず、個々のコマンドはスクリプトに変換され、SSHの代わりにホストで自動的に実行するようにしました。それぞれのチームがPagerDutyで独自のサービスを開始した後にこのツールを使用することで、SREチームを必要とせずにフォルトインジェクションができるようになりました。

しかし早い段階で、各サービスの責任者が既知の障害を起こすプロセス作ることにしました。これは、毎週金曜日に責任者が何を調査すべきかを少なくともいくらかは認識していることを意味していました。それは、彼らが問題を解決するためのスタートでした。

現実の世界では障害の予兆が出ることはめったにないため、任意のホストでランダムに攻撃のサブセットを実行できるようにすることで、システムに偶然の要素を導入したいと考えていました。そのため、ツールを追加してランダムにホストを選択し、それらに対してカオス攻撃を実行しました。パズルの最後のピースは、すべて自動化されたスケジュールにまとめられていました。

実装

ChaosCatはScalaベースのSlackチャットボットです。分散型タスク実行エンジンなど、我々のインフラのいくつかの別コンポーネントの上に構築されています。Chaos Monkey(Netflixが開発、利用しているオープンソースのフォルトインジェクタ)の影響を強く受けていますが、我々のインフラにはさまざまなサービスタイプが存在するため、サービス実装には依存しない設計になっています。

ChaosCatは常時稼動のサービスとして動作しています。これは、許可されたチームがいつでも使用できることを意味します (「@chaoscat run-once」で実行) 。サービスがアイドルの間はスケジュールが1分ごとにチェックされ、オンコールエンジニアがいることが確実な営業時間中にランダムに障害を発生させます。

営業時間になったら、システムステータスがすべてクリアかどうかをチェックします。サービスの健康状態が100%でない場合には障害を発生させないためです。

次にインフラ内の無作為に抽出されたホストに対してランダムに選択されたカオス攻撃(異なる選択確率を持つ異なるアタック)を発生させます。現実世界では例外なくすべてのホストが同様に脆弱だからです。社内のジョブランナーを使用して、Blender実行フレームワークを介してカオス攻撃を実行するタスクを送信します。

10分待ってから、スケジュールされた営業時間の間に、2つ目と3つ目のステップを繰り返し実行します。問題が発生した場合、誰でも「@chaoscat stop」を送信することによって攻撃を停止することができます。

学習

いくつかのチームは、こうしてダッシュボードとログの準備が整った状態で座っている時と、モーニングコーヒーを飲んでいる間にトラブルが生じた時とでは何か違いがあることをすぐに知りました。これらのチームは、ランニングブックとオンコールローテーションのギャップを特定し修正しました。大成功!

もう1つの興味深いことは、チームが最初の苦労を乗り越えた後、以前に手作業で行われた修正を自動化し、バックログに不具合の優先順位付けしたことです。その結果、このチームはサービスの信頼性に自信を持ちました。

残念ながら、ChaosCatは社内のインフラストラクチャツールに大きく依存しており、現時点では、オープンソースではありません。しかし、私たちはあなたのフィードバックと質問をお待ちしています。

このような信頼性のためのエンジニアリング―カオスエンジニアリングを開始する企業が増えることを期待しています。それは複雑さと多様性が増すインフラの堅牢性と動作を検証するうえで素晴らしい方法です。

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

スケーラブルな分散システムを構築する

予防は最高の薬です

分散システムを構築する最善の方法は、 分散を避けることです。その理由は簡単で、分散コンピューティングの欠陥を迂回することができます(一部の楽観主義者の考えとは異なり、分散コンピューティングの欠陥はまだ残っています)。

私の個人用のラップトップにはSignalFXのステッカーが はってあります。これは、さまざまなトランスポートメカニズムの速度のリストです。そもそもこのステッカーは、特にデータセンター間を移動するときに、複数のディスクやネットワークを使うのを避けるようにと言っています。それに従い、機械的な共感を抱くならば、単一ノード上で毎秒何百万件ものトランザクションを実行できる取引プラットフォームをサポートできる、LMAXのように市場を破壊するような素晴らしいものを構築することができます。メモリや単一のマシン上で処理させるようにするとさらに多くの処理ができます。おそらく15秒分の作業をやり直しても問題ない場合は、メモリ内ですべての作業を行い、1分に4回チェックポイントをディスクに書き出すだけです。そのようなシステムは非常に高速に動作し、完全にスケールアウトするという問題を回避できます。

自分自身をだますことはできません – 分散システムは常に複雑さを増し、生産性を低下させます。もし誰かが別のことを言うのなら、その連中はおそらくいんちきなものを売っているのでしょう。

なぜそうしているのかを調べ、前提をすべて問い直してください

「高可用性」と呼ばれる要件のせいで、すべてのコードを1つのノードに置くことが不可能になります。この要件は、しばしば、複数のシステムが引き込まれるまで非常に高価なステップを引き起こします。ここでは、2つの要件、チャレンジの仮定とチャレンジの要件があります。この特定のシステムには本当にファイブナイン(訳注:99.999%)の可用性が必要ですか、それとももっと 緩い可用性を与えるレイヤーに移行できますか?特にあなたのソフトウェアがそれ自体を証明する必要や、HA(高可用性)やその他の鐘や笛を鳴らす必要があるのならば、成熟度の低い最適化を施してしまう可能性があります。そうではなく、今すぐにスキップして、市場投入を早め、後で追加する戦略を立ててください。ビジネスのステークホルダーが「はい」と言うなら、「HA」にする必要がありますが、トレードオフと、時間とお金を使う実際には使えないものに時間とお金を費やすことになるかもしてないことを相手が知っていることを確認する必要があります(顧客がその製品や機能を気に入らないようになるという結果も考えられます。顧客が好きになることを知っている製品や機能だけを作ってればリスクはなく、あなたが始めたベンチャーは退屈な雲の上に止まってしまいますが)。

CAPの定理を説明すると利害関係者に、可用性や一貫性を持たせられるということは言えますが、両立は無理です(もう一度言っておくと、楽観主義者の中にはそれは問題ないという人がいますが、間違っていると思います)。 たとえば、通知を送るシステムを構築した場合、たいていは、一貫して通知を送るシステム(一貫性がありますが可用性の低い通知)とか、ほとんど常に通知を送理続けるシステム(可用性はある一貫性が低い)を作ることはできます。 通常、最終的に一貫性のある(AP)システムは、調整が少なくてすむため、構築が楽で、拡張と操作が簡単です。可用性の要件を取り除けるかどうかを検討してみてください。 普通は、APソリューションで問題解決を図ることを検討することは価値がありますので。

忘れないで – 何かを避けられないなら、少なくとも単純にする方向で交渉してください。 複雑な分散システムを実装しないことが、分散システムを構築する最善の方法です。

人生をシンプルにする

複雑さは我々の商売の敵なので、どんなコードを書いていても、どのようなシステムを設計していても、この「複雑さが膨れ上がったらハンマーで叩き潰す」というモグラ叩きゲームをプレーする必要があります。 複数のシステムにまたがるソフトウェアを書いたらすぐにこれはさらに大事になります。分散システムは本質的に複雑なので、偶発的に複雑さが増すことには我慢しないようにしてください。分散システムの中には、他のものより実装が簡単なものがいくつかあります。単純なものに固執し続けることです。

HA用に配布する

可用性を向上させるにはいくつかの方法があります。ノードのクラスタを作り、すべてを調整できます(作業状態を常に保存しておくと、どのノードでもなんでも拾えるようになります)が、それには多くの調整が必要です。 調整はシステムを壊れやすくするので、おそらく維持できないのではないでしょうか。 コーディネーションを避けるためのさまざまな選択肢があり、依然として優れた可用性を保てます。

同じ作業を複数のシステムで並行処理させ、1つのシステムの出力のみを使うこと。 すべてがセカンダリノードにレプリケートされるため、プライマリノードに障害が発生すると、レプリケーションによってバックアップノードが確実に「ホット」になり、瞬間的に引き継ぐことができます。調整が必要なのは最初にどのノードを実行し、どのノードを2次バックアップにするかを決めることだけです。 予備の待機系を持つこと。 プライマリノードは定期的に共有ストレージ上で作業を継続し、作業が停止すると、セカンダリがそれを読み込んで引き継ぎます。 ここでの調整は、通常、テイクオーバーが必要かどうかを知るために、常にセカンダリがプライマリを監視するようにしておくことです。

どちらの場合も、調整の単位は「トランザクションごと」から「構成ごと」に移行します。分散した作業トランザクションの扱いは難しいので、構成レベルの調整を取り除くことができれば、そうしてください。しばしば、これにはいくつかの作業が含まれます。「正確に1つ」の作業プロセスは、マシンが死ななければ「ほとんど正確に1つ」のプロセスになり、何も見逃さなかったことを確実にするためには最後の1分まで再生してみる必要があります。場合によっては、重複したオペレーションが表示されるのを避けることはできませんし、要件に関してステークホルダーとチャットする必要があります。正直なリスクアセスメント(1年に何回くらいそのマシン群は死ぬのか)と、正直なインパクトアセスメント(どのくらい各要素が重複する作業をしたのかと、ユーザーにどのくらい不便を感じさせたのか)と正直な難易度アセスメント(ぜい弱性を生じさせ、これにより可用性が低下するような余分な作業と複雑さがどれくらい増えたか)を実施しましょう。

場合によっては、データセンターに障害が発生した場合にも可用性が必要になることがあります。そのような場合には注意が必要です。システムが脆く、早くなりすぎるので、最小限の調整で済むようにしたいと考えるようになるでしょう。

パフォーマンスのために分散させる

一つのノードだけですべての作業を完了させることはできない場合もあります。まず、そんなポジションをとらないようにしてください。目をしっかり開いて、サイクルを無駄に使っているところを探してください。LMAXの人々は、1台のマシンで1秒あたり7桁のトランザクションを実行できることを示しました。より大きなインスタンスが必要ならAmazonを使うべきでしょう。私はまともなソフトウェアとは、より速いハードウェアを手に入れれば迅速に修正できるようなマルチコア対応のものだと、今のところは思っています。より多くのコアでより速く実行できるようにコードを書けない場合は、たぶんノードを追加しても高速化は期待できないのではないでしょうか? LMAXレベルのエンジニアリングがなくても、少なくとも1秒あたり5桁のビジネスオペレーションをソフトウェアが処理できると問題を解決するためにマシンを追加する必要がある場合(これは大きな問題です)、調整が最小限になるように計画してください。

想定してよいと思います。 1ノードでは1秒間に数百個も処理できないのでスケールアウトしたい、というのなら、最初の設計をしたボードに戻ってください。おそらく、あなたのコードには対処が必要な別の問題があるのです。

問題を解決するためにマシンを追加する必要がある場合(これは大きな問題です)、調整が最小限になるように計画してください。

トランザクションの調整ではなく構成の調整をする。さらなる協調の必要なしに各ノードがそれ自身のチャンクをプロセスに実行させるための調整スキームをノードに使わせます。あるノードが使えなくなったときに各ノードが再配布できるようにすれば、HAを非常に簡単に追加できます。 どんな調整も全く必要としないように、並行できる作業を見つけること。 ステートレスなWebサーバーが良い例としてここに挙げられますが、調整されていないノードの束を投入できるのはそこだけに限りません。

ストレージは安いのだから活用しよう

コマンド/クエリ分離やイベントソーシングなどのアーキテクチャパターンは、データストレージを複数の特殊なステージにデカップリングし、複製することがよくあります。これらの特殊なステージは、分散設計をサポートするためにはうまくいきます。ローカルに保存するものと分散するものを選択できるため、調整を最小限に抑えるハイブリッドソリューションになるからです。たとえば、アップデートコマンドを分散Kafkaクラスタに書き込むことはできますが、そこからの下流のすべてはローカルで操作できます(たとえば、コンシューマがアップデートコマンドを処理し、クエリに使用されるElasticSearchノードを個別に更新します)。 「実際の」データは、利用可能性が高く、メッセージストリームで調整されます。システムは、検索、分析などの特殊な処理のためにそのデータのビューを使用します。このようなシステムは、中央のデータベースシステムがすべての操作のネクサスであり、必然的にボトルネックになる古典的な構成(データベースシステムがスケーラビリティのために構築されたものであろうとなかろうと)よりも簡単に維持できます。

データを冗長に保存し、複数の独立したシステムがそれぞれ独自の最適化された形式のデータを使用するようにしてください。そうすれば調整の必要性が低くなり、最終的にはストレージコストは比較的小さな増加で済むようになります。

NIH症候群を避ける-車輪はすでに他の場所で再発明されている

Googleのスケールでシステムを運用するのでない限り、分散型であなたが実装しようと取り組んでいるシステムは、一から自分で構築する必要があるほど特別なものではないはずです。あなたが投資をしているのはビジネス上の問題を解決するためであって、ツールやインフラストラクチャを構築するためではないでしょうから、2017年の今、自分のための特別な何かを探す理由はないのです。分散システムを正しく実装するのは難しいので、失敗する可能性が高いのです(パーシステンスと暗号化についても同じアドバイスができます)。独自の問題を抱えていて自分自身で何かを発明する必要があると思っている場合は、実はちゃんとじっくり世間を見ていないか、何百ものオープンソースプロジェクトのどれかが使える形に、自分の問題を定義し直す努力をしていない可能性があります。あなたは「ビジネス」を推進しており、分散ソリューションをずっと簡単に、したがって信頼性を高める形で要件の形を変えるのを助けています。あなたが抱えている問題の、ユニークではない部分を解決するための、正しいソフトウェアを見つけましょう。そうすればあなたは自分の会社を特別なものにすることに集中できるようになります。

そう、ツールを作ること(tool-smithing)は楽しい – 私も大好きで、一日中やっていても飽きません。そして、確かに、独特の雪のかけらみたいに見えるような形であなたの問題をフレーミングすることは、自尊心のためには良いことです。でもそれは辞めて、ビジネスを成功に導くために本当の問題を解決してください。

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

DevOpsカルチャーを構築するためのガイド

DevOpsを知った時期によって、DevOpsの実装方法に関する認識は変わります。DevOpsはまず文化のみの動きとして始まり、成熟するにつれてますます戦術的になりました。

文化がDevOps環境の中心にあります。 多くの場合、文化はDevOpsにとって最も難しい部分です。また、DevOpsの文化を構築するための万能薬はありませんが、私が以下で説明するように、働いている組織の種類に無関係に、健全な文化を定着させるのに役立ついくつかのテクニックがあります。

なぜ文化が大事?

文化という言葉はお嫌いかもしれませんし、大好きかもしれませんが、それは問題ではありません。文化に関してそういうことは環境に関係なく常にあるものだからです。 文化が意識されていない開発環境では、それ自体が有機的に作成されますが、これは通常、あまり望ましくないシナリオになります。 それは独裁国家(fiefdoms)の文化、あるいはすべてが壊れやすく、すべての新機能はそれが書かれる前でさえ失敗とみなされる、恐怖の文化かも知れません。。

だから、どんな場合でも文化があります。 DevOpsの原則が作ろうとしているのは、意図的に作られた文化です。組織は、その目的を最もよく支える文化を事前に決定し、その枠組みを確立し、向上させ、維持するために必要なことを行います。

DevOpsの文化が悪い印象を持たれているのは、それはしばしばヒップスターやスタートアップに関連する言葉だからです。 しかし、これは正確ではありません。その文化の要素のいくらかはスタートアップのロビーに属するように見えますが、DevOpsを意図的に文化として広げようとする触媒はボトルネックを避けられるかもという希望でした。あらゆる種類のプロセスとツールを採用してより速く開発を進められるはずですが、意思決定に加わっていないユーザーにより速度が制限されると、高品質でより頻繁で高速なリリースは実現できません。

文化の問題のもう一つの理由は、DevOpsは単なるプロセスやツールではないからです。 これは、DevOpsに対応しないスタティックな環境にデリバリーチェーンがならないようにすることを目的に、作られています。プロセスとツールだけで開発運用を「実装する」場合、2年後にはその環境はウォーターフォールのようなルック&フィールになり、現在の開発の標準に追いつけなくなります。

文化を快適にする

適切な文化を醸成することは、組織が、「より良いソフトウェアの品質とスピードを促進する文化をサポートし成長させる必要がある」と認めているほど簡単です。、いくつかの明確な目標を持ちどう行うべきかを意識し始めると、すべてのチームメンバーにとってその文化が最優先事項になります。 彼らは新しいツールを採用する際に、ツールがどのようにモジュール化でき、スクリプト化できるかを考えます。 あるいは、他のチームメンバーとのコミュニケーションについて考えるとき、彼らは簡潔に結果が得られることに重点を置くでしょう。チームがポジティブな文化を築くためにできることは、組織がより良いコードの文化に専念していることを明確にすることに加えて、他にもいくつかあります。

管理責任を持つこと(独裁ではなく)。 あなたが欲しい、または必要とする文化は、トップダウンでの導入を必要とします。でもそれは指示されるべきではありません。文化を支えるために、チームメンバー(リーダーシップとエグゼクティブの両方を含む)は、人々にどのように行動すべきかを伝えるのではなく、文化を積極的に実践してメリットを見せる必要があります。 あなたは誰かにチームプレーヤーであることを伝えることはできません。チームプレーヤーであるという利点を示す必要があります。 しかし、これは、誰かがその環境内に収まらない場合、彼らが歩き回っても良いようにするか、組織から去らせることで収拾する必要があることを意味します。 成功を分かち合うこと。 チームがそのメリットを理解するためには、リリース頻度の増加、欠陥の減少、人間の関与を必要としないタスクやリリースが増えるといった成功を共有する必要があります。チームの全員がより効率的な環境のメリットを享受できるわけではないので、そのメリット(革新的なビジネスの差別化要因の企画や繰り返しの少ないタスク、バーンアウトの削減などに専念する時間)を、常にチーム全体で話し合う必要があります。 チームを小さくする**。 強い文化を維持するには、より小さくて緊密なチームに保つことです。 これは階層の問題であり、リーダーシップは絶対に関与する必要があります。 アマゾンのようなハイテク企業の指針は、すべてのチームが「ピザ2枚で足りる」少人数のチームでなければならないということです。すべてのメンバーがチームへの貢献度を明確に把握し、作業の可視性を確認する必要があります。 これは、各チームが協力して文化を維持し、直接的な説明責任を持つようにするのに役立ちます。 目的をシェアする**。 組織がしばしば間違っている点は、競合する目標を設定することです。 チームメンバーが常にある測定方法で評価されながら作業するので、例えば開発者が発表した新機能の数で評価されているのに、運用チームは物事が中断しないことを基準に評価されている場合、これらの2つは直接衝突します。変化はOpsの心のリスクと等しいので、新しいものに対してサポートするのではなく、それをリリースをさせないように動機づけられるからです。経営陣は、同じ目標を達成するためには、全員を同じ基準で評価する必要があります。

階層やKPIのようなものは、常にあなたが制御できるとは限りません。もちろん開発者でもボトムアップで、共通の文化の価値を表現することができます。ある時点では、組織と管理者はその光を見る必要があります。 良いことは、すべての企業がある程度の能力を備えたハイテク企業になるにつれて、以前より高い品質なアプリケーションリリースを頻繁にサポートすることを支援する必要性は収益に影響します。 経営陣は数字以外を聞くことはありません。

文化をOKにする

文化はとても主観的なので、効率の環境を維持する原則とは対照的に、DevOpsの戦術にフォーカスするほうが簡単です。 文化エンジンを地面から降ろすのは難しいですが、良いニュースは、いったんそれが始まると非常に自立しているということです。 文化の鐘を鳴らすことは難しいです。これは、あなたがそれを作成することを熟考したとしても当てはまります。

上記のフレームワークとともに、ボールを投げて、結果が出るまで耐える自信を持つことが、成功への鍵です。 DevOps文化を受け入れる組織は、ソフトウェア配信をよりシームレスにして、最先端の開発の実践をより成功させるでしょう。

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

インシデントの経験を事後検証で最大活用

インシデントを経験した後 のポストモーティム(事後検証。post-mortem またはpostmortem と表記される)に 何をします? 簡単な質問のように見えるかもしれません。 結局のところ、インシデントの処理の最後のステップとして事後検証を考えるのは簡単です。

しかし、そうではありません。 多くの点でインシデントのポストモーティムで何を検証するかは、ポストモーティムをすることと同じくらい大事なんです。以下、理由を説明し、事後検証が終わったあとに何をするべきか、そのヒントを提供します。

なぜポストモーティムするの?

しかし、この質問の意味を考える前に、より根本的な質問、つまりポストモーティムの機能とは何か、そしてそれには何を含めるべきかを検討する必要があります。

ポストモーティムは基本的に以下の役割を果たします:

インシデントとその原因および関連する兆候、解決策、将来の参考になる影響の記録を提供する。技術的問題を将来理解するためと、事件から生じる法的または行政上の懸念の解決の両方にとって重要になり得る。 事件を引き起こした基本的な技術的問題を分析し解決するための基礎として役立ちます。 インシデント対応プロセスを理解し改善するためのフレームワークを提供します 。

これらの基本的な役割をサポートするために、ポストモーティムにはインシデント、対応、解決の記録が含まれていなければなりません。 また、インシデントの根本原因の分析 、インシデントの範囲とその影響の説明、根本的な問題の解決、対応プロセスの改善、および/または将来のインシデントの影響の最小化のために適切な推奨事項も含める必要があります。

理解したあとに、責めないこと

大事な注意点ですが、ポストモーティムを責任追及の手段にしてはいけませんし、企業や組織のポリシーに点を付ける手段にならないように注意してください。必要ならば、事後検証から責任追及を分離するためにインシデント関連の問題を議論するために別のプロセス(すなわち、部門内での非公式で司会を立てた議論)を設定してください。

一方ポストモーティムでは、インシデントを起こす背景になった可能性のある、または対応中に明らかになった、技術的または組織的問題についての正直な議論が含まれるべきです。 技術や反応プロセスの改善に重点を置くべきであり、個人やチーム、あるいはその仕事の欠陥に置くべきではありません。

ポストモーティムはいつ必要?

すべてのインシデントでポストモーティムをする必要はありません。 軽度の運用上の問題や、よく原因が分かっており簡単な解決策があるインシデント、そしてダウンタイムやデータの消失が起きなかったインシデントには、ポストモーティムが必要ない場合があります。

ポストモーティムが必要な状況の例をいくつか示します。

データや生産性の低下、または顧客のアクセスにつながるインシデント シャットダウン、再ルーティング、以前のソフトウェアバージョンへのロールバック、および/または解決のための長期のアクションが必要だったインシデント 適切な監視やアラートシステムがあったのにうまく検出または処理されなかったインシデント 根本原因が不明、あるいは予想を超えていた、または今後も発生が疑われるインシデント システムの動作に広範囲の影響を及ぼす可能性のある、アプリケーションアーキテクチャや技術の根本を含むように見えるインシデント 回答や解決プロセスに深刻な問題や不備があったインシデント

ポストモーティムは学習を容易にする

ポストモーティムを価値あるものにするにはその書き方を、長期的な問題の分析、解決、防止を担当する人々が読みやすくかつ理解しやすくする必要があります。

これは、例えば、問題やその解決を抱えているチームや部署は、ポストモーティムの記録を読むことを読み、さらに結果として適切な次のステップを決定するために、できるだけ早く議論に参加することを要求されているからです。 どうポストモーティムの資料を流通させて、それらを読んだあとの行動にどう導くかという実際のプロセスは、もちろん、あなたの組織の構造と経営理念に依存します。

ポストモーティムの基本要素

ポストモーティムを書いたり読んだりするときには、次の3つの重要な分野があります。

根本的な原因

ポストモーティムは必ず根本原因の説明を含むべきです。根本的な理由が既に分かっていても、ささいなことであっても。ささいな原因ではない場合は、問題の実際の根本原因を正確に特定し、それを修正する必要があるかどうかを、原因の分析に含める必要があります。 根本原因を正確に特定できない場合は、将来の特定につながる可能性のある情報を含める必要があります。

例えば、インシデントの解決の過程で、その問題が多量のレガシーコードを含むモジュールで生じたことが明らかになったけれども、そのモジュールよりも下の部分にある根本原因を特定できなかったという場合でも、その事実を根本原因の分析に含めることが重要です。インシデントと関連してレガシーコードを特定したという事実の記録は、インシデントの解決だけでなく、後の調査で置き換える必要のあるコードを特定することにおいても価値があります。

対応

ポストモーティムには、対応プロセスの完全な技術的説明が含まれていなければなりません。 また、そのプロセスの相対的に見た成功または失敗の説明と分析も含める必要があります。 これは誰の責任も問うことなく実施されなければなりませんが、対応プロセスまたはそのプロセスの実施中の明らかな失敗や弱点を明確に示すべきです。 これには、対応チームメンバー間の責任分担、対応チーム内の連絡、または対応チームと他のステークホルダーとの間のやり取り、特定の対応プロセスの問題が含まれます。

対応プロセスの失敗は、技術的または組織的なものに及ぶ可能性があります。インシデントの解決中にシステムやアプリケーションが利用できないことを、その影響を受ける部門やユーザーに伝えられなかったというような、簡単なことが含まれます。 2つのチームのメンバーが協調せずに同じタスクを実行してしまったり、誰も必要なタスクを実行しなかったために、結果として解決に時間がかかりすぎた場合は、ポストモーティムの中にはチーム構成やコミュニケーションの潜在的な問題を示す注記を入れておく必要があります。

被害の影響範囲の確認と制御

ポストモーティムには、データの損失、生産性の低下、ユーザーアクセスの中断など、インシデントによって引き起こされた損害の程度を明確かつ正確に記述する必要があります。 この被害を限定あるいは緩和するために取られた措置についての説明と分析を含めることも同様に重要です。 ダメージコントロールは、技術的なインシデント解決とは別のプロセスとして考慮する必要があります。 インシデントの種類、被害の種類、および組織の構造によっては、カスタマーサービスの責任である場合や、ビジネス内の他の部門のアクションアイテムが必要な場合があります。

ダメージコントロールは、似たようなインシデントを将来どう処理すべきかに直接または間接に影響する可能性があるため、ポストモーティムの一部に入れておく必要があります。 例えば停電により航空会社のフライト予約システムが停止した場合、そのダウンタイム中に予約を処理するための代替システムを導入することを優先する必要があるかもしれません。

恥と思わず、金と思え

ポストモーティムを最大限に活用するための鍵は、これがアプリケーション、インフラストラクチャ、および対応プロセスの改善のためのロードマップであることを理解することにあります。 各ポストモーティムは、システムの動作方法とインシデントの処理方法を改善する可能性があります。 ポストモーティムを恥とか何らかの失敗の徴候として扱うのではなく、これは将来の金になる貴重な機会だと考えるべきです。

PageDutyは、業界のベストプラクティスを共有し、ポストモーティムのテンプレートを含む完全に無料のポストモーティムハンドブックを提供します。 あなたのチームが問題にできるだけ簡単に対応できるように、自分のポストモーティムプロセスを正式化するのに役立ちます。 PureDutyプラットフォームの一部であるポストモーティムは、自動化されたタイムライン構築、コラボレーティブな編集、実用的な洞察など、 14日間の無償体験版にサインアップし、ポストモーティムのプロセス全体を合理化します。

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

DevOpsを高速化するための6つのステップ

多くの組織がDevOpsの導入を検討しているのは、リリース速度の向上、開発速度の向上、開発者がイノベーションに集中できる時間を確保できることなどが期待されているからです。しかし、DevOpsの採用は万能薬ではありません。その代わり、DevOpsモデルが奨励するコミュニケーション、コラボレーション、批判しない前提での振り返りの考え方は、問題を解決するだけでなく、プロセスを改善してボトルネックを解決し、より無駄のないシステムを構築するのに役立ちます。

DevOpsを実装する組織にとって最大の課題の1つは、ワークフロー内の既存の問題を特定して削除し、より新しく、よりアジャイルな方法論に道を開くことです。ガートナー社は、システムが目標達成に近づくのを妨げる不便さ、挫折、その他の制限要因を意味する制約を取り除き、真の意味でDevOpsの速度を向上させるために組織が取ることができる6つのステップを以下にまとめました。

ステップ1:プロセスを定義する

プロセスを再構築する際には、DevOpsチームは、初期の構想から最終的な顧客価値に至るまでのワークフローをデザインし、プロセスを定義する必要があります。既存のプロセス内のすべてのステップを文書化することにより、プロセス全体に積極的に貢献していない可能性のある制約領域をより簡単に見つけ出し、改善できます。さらに、サイクルタイム、おおよその時間間隔、ハンドオフ、待機状態など、より価値の高い流れを明確に把握できます。これがすべて整理されたら、チームは最大のプロセス制約を簡単に特定し、プロセス全体を改善するための手順を開始し、プロセス文書化の効果を高めることができます。

ステップ2:最大の制約を特定する

典型的なDevOpsのワークフローでは、アイデアから価値へのプロセスを遅らせる段階が常に存在します。体系的な改善を推進するために、チームは進行を妨げている特定のフェーズを特定し、制約の原因を取り除く必要があります。

最大の制約を特定するには、「誰もが常に何を待っているのか」を問います。これを尋ねることで、チームは効率を高めるために特別な注意が必要なことを特定できます。責任追求をしない建設的な環境でこれを行うと、チームメンバーは発言しやすくなります。最大の制約を特定したら、プロジェクトの進行状況を監視して、ブロック要因が正しく特定されていることを確認します。

ステップ3:制約条件下での無駄を取り除く

制約が特定された場合、最も一般的な行動方針は、より多くのリソース(人、お金、新しいシステムなど)を投入することです。ただし、役に立たない可能性があるリソースを追加するのではなく、無駄な可能性のあるリソースを排除することがより効果的です。

ガートナーによると、クライアントが特定した上位3つの無駄の発生源は次のとおりです。

インシデント:** 新しい製品や機能の開発などの付加価値活動を犠牲にして、インシデント管理に貴重な時間が費やされています。このためのベストプラクティスは、チームメンバーを相互訓練してインシデント管理に習熟することです。将来のインシデントを防止する1つの方法は、責任追求をしない事後検証を実施して、インシデントの根本原因を解明し、将来それを防止することです。 待機:** 人、外部組織、その他のリソースを待つことは、常に課題です。これは、多様なスキルと知識を備えた従業員をトレーニングや雇用して、並行して作業できるようにすることで軽減できます。これにより、他の人の対応を待っている間に、プロジェクトの目標や他の割り当てられた仕事を達成することができるようになります。 人のポテンシャル:** データベースの更新であれ、インシデントのエスカレーションであれ、多くのIT専門家は多くの時間をかけて手動で作業しています。組織はできる限り自動化することでより多くの価値を実現し、人々はより価値の高いタスクに集中できるようになります。

ステップ4:制約を無視しない

制約を無視して新たに発生した問題に集中すると、元の問題に対処できなかったため、作業が遅くなり、将来さらに問題が発生します。たとえば、鎖について考えてみましょう。鎖の中の最も弱い環が強化されていない場合、鎖はある時点でその場所で切れてしまいます。

制約を無視することで、チームは次のようなさまざまな課題を経験することになります。

ミスや欠陥の増加 チームの効率と生産性への悪影響 変化率の高い状況での費用のかかるやり直し

ステップ5:容量を追加する

上記の手順は、スループットを少なくとも30%向上させるのに役立ち、問題を評価する能力と時間を利害関係者に与えるので、迅速な解決策を選択するのではなく、最善の解決策を慎重に検討できます。チームは専門サービスの契約であろうと追加のスタッフの採用であろうと、キャパシティを増やすことができる他の方法を見つけるためにこの時間を取るべきです。

ステップ6:次の最大の制約を見つける

リリース速度を向上させることは簡単なことではなく、プロセスを継続的に改善する必要があります。例えば、あるチームが制約を取り除くことに成功したとしても、ワークフローの別の部分で別の制約が取って代わることがあります。時間が経つにつれて、チームは高い開発スピードを達成するために、プロセスとプラクティスを適応させる必要があります。最後に、顧客のニーズを確実に満たすためには、開発サイクルのデューデリジェンスを実施し、必要に応じて改善する必要があります。

ガートナーの完全なレポートをお読みになりたい方は、「制約を削除してDevOpsのリリース速度を向上させる6つのステップ」をご覧ください。

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

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

オンコールのシャドー中に驚いた5つのこと

シャドーイング( 訓練のためインシデント対応を見学すること )中のコールエンジニアは、医師の肩越しに開腹手術を見ているような感じがします。精密さとスピードが最優先事項であり、間違いは深刻な結果につながります。私はPagerDutyエンジニアリングチームのオンコールローテーションにシャドーオブザーバーとして1週間参加しました。

オンコール中、私は同じエスカレーションポリシーで、他のすべての人たちと同じように通知を受けました。エンジニアが緊急でセンシティブな状況に立ち向かうため、Slackで起こされると私も起こされます。私はストレスが人々を悪い状況に追い込むと予想しました。ところが、驚いたことにそれは完全に間違っていました。

コールは睡眠、食事、シンプルな文章は、何時間ものストレスを乗り切れるようにします。

思考、そしてほかの多くのものを中断するために鳴り響き、チャットチャンネルは一晩中炎上と対応を知らせるメッセージを流し続けました。オンコールの責任とストレスに押しつぶされそうなのに、エンジニアが見せる優しさ、助け合い、ユーモアに私は驚かされました。

励まし

シンプルな文章は、何時間ものストレスを乗り切れるようにします。

初日のシャドーイングの午後遅くに、私は最初の通知を受けました。私はSlackのチャンネルを見て、問題の調査が完了したのを知りました。チームは直ちに新しいマシンを停止し、再配置をしました。トリアージと診断の混乱の中で、そのオンコール担当者が私と同じく新人だと知りました。私たちはどちらもまだ1カ月足らずの新米でした。彼はこれまで一度も遭遇したことのない問題を修正していました。

夕方までに事態は回復しました。長い1日を終え、人々は家に帰って行きました。それでも、ベテランのエンジニアPがチームメイトKの応援に入っていました。

6:14 PM (P)すべて終わった?

6:15 PM (K)まだ、ホストを再起動してるところです。すべてがスムーズに進んでます

6:18 PM (P) その調子だ! 俺達はこいつのために半日つぶしたんだ

このような仲間の励ましは、プロジェクトに新しく加わった人、新人社員、新人エンジニアに自信をもたせます。シニアエンジニアからの励ましは経験の少ないエンジニアに質問する勇気を与えます。質問は新人がエキスパートになるための第一歩です。「その調子だ!」の一言は人々に力を与えます。

謙虚さと感謝

この初心者オンコールエンジニアは、その励ましにすぐ反応しました。彼は自分を助けてくれたシニアエンジニアに短い言葉で謙虚さと感謝を示しました。

6:21 PM (P)本当にあなたとMがいなければダメになるところでした。勉強になりました

Kが彼を助けた別のチームメイトの名前を挙げたのが嬉しかったです。DevOpsのエンジニアリングチームは、チームメイトを高く評価しています。彼らが今開発しているソフトウェアが明日、地獄のオンコール嵐を起こさないため、互いに頼り合っています。誰も常にすべてのことを知ることはできません。彼らは常に互いから学び、お互いに助け合わなければなりません。

上の例では、謙虚さと自己嫌悪の間の細い境界線が見えました。エンジニアは「学ぶことがとても大事」と述べています。この態度は「こんなことは絶対自分ではやりません」や「私にはこんなこと全部分かるわけないでしょう」とは異なります。謙虚で感謝の気持ちがあれば、チームメート同士の信頼を築けます。自己嫌悪は迷いと不安を引き起こすでしょう。

軽薄さとたくさんのGIFファイル

オンコール待機中は(幸せなことに)退屈でもあります。オンコールに入る予定が分かっていることはストレスを軽減してくれますが、それでも常に不安があります。幸運なことに、インターネット上のGIFファイルは、ストレスに満ちたオンコールシフトをユーモアで支えてくれます。

PagerDutyはユーモアの文化とカスタムGIFに特別な情熱を持っています。3つのタイムゾーンと2つの異なる国に分かれているこの楽しくてちょっとおバカなチームを観察するのが私は大好きです。オンコールでない人々がいつも明るいことに気づきました。

どうすればオンコールをよりポジティブにすることができるか

あなたがオンコールでない場合でも、チームと共にあれ 応援しよう。特に新人を 挑戦やリスク、時間のかかることを肯定する 感謝をもってあなたに直接影響を与えてくれた人々に接する。チームが将来どのような強みを持つか理解するのに役立つ ひょうきんに振る舞う。皆笑うのが大好き

たくさんの問題解決と心労を経験しましたし、他人が週末や夜にもオンコール待機をするところも見ました。そのまっただ中で、チームメイトが示す小さなジェスチャーが、あなたが1人ではないことを思い出させてくれます。

空が落ちてくると思うような時は、互いに品性ある振る舞いをすることが助けてくれるでしょう。

<  123  >