Blog
ブログ

2018年2月11日  (更新日:2022年3月11日)

Sensu Coreインテグレーションガイドを追加しました

Sensuは、サーバー、サービス、アプリケーションの健全性とビジネスKPIのためのオープンソースの監視フレームワークです。 Sensuは、AWS EC2インスタンスなどのクラウド内のシステムを監視するために設計されたものです。このガイドでは、Sensu CoreとPagerDutyを統合するプロセスについて説明します。なおこのガイドの手順はSensuの無料版であるSensu Core用です。 Sensuのエンタープライズ版にはPagerDutyとの統合機能が組み込まれています。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年2月9日  (更新日:2022年3月9日)

Datadogインテグレーションガイドを追加しました

Datadog はメトリックとイベントを1か所に集約してくれるホスト型の監視サービスです。Datadog とPagerDutyのアカウントを統合すると、Datadogのニュースフィードにある@pagerdutyというメンションでPagerDutyにDatadogのアラートを送れます。Datadogのニュースフィードでインシデントやエスカレーションをリアルタイムに追跡することもできます。PagerDutyにDatadogアラートを送信することで、PagerDutyのアラート機能をフルに活用できます。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年2月8日  (更新日:2022年3月10日)

デジタルオペレーションを人間的に

午前3時、あなたは暖かく居心地良い布団の中で、枕に垂らしたよだれに気づかぬまま、深い夢の中で癒されています。

ところが突然、あなたは目が覚め、心臓が高鳴ります。電話が最大音量で鳴っています。隣で寝ていたパートナーは目を開けて寝返りを打ち枕を頭にぶつけ、眠りに戻る前にあなたを睨みつけます。あなたは電話を黙らすために手を伸ばし、アラートの発生を知ります――夜間のバッチジョブがまたトラブったようです。 あなたは一言怨嗟の声を上げ、ノートパソコンの前に座って2時間の仕事に就きます。気が付けば夜明け。あなたは睡眠不足で疲れていますが、数時間後にはオフィスにいなければなりません。

いつものことですか?

微妙なワークライフバランス

今日の常時稼働の世界では、これがオンコール担当者の日常です。健全なITエコシステムを維持するのは、昼夜を問わず準備ができていることを要求する厳しい仕事です。最近のPagerDutyの報告書「グローバルITワークライフバランスの現状」によれば、ITエンジニア800人を調査したところ、51.3%は週に10回以上、仕事や生活が中断されたと答えています。 IT運用は担当者の健康を犠牲にしながらインフラとアプリケーションの健全性に重点を置いてきました。オンコール対応者は勤務時間中と時間外に関わらず、週末にもアラートを受信し、疲れ、欲求不満が高まり、睡眠不足に陥っています。担当者だけがストレスを感じているわけではありません。その家族も同様に影響を受けています。

これは広範な問題です。調査の回答者の94%が、アラートが家庭生活に影響を与えると答えました。ほぼ同数の回答者(94.5%)は、アラートによる中断が仕事の生産性に悪影響を及ぼしていると回答し、72%は彼らの上司は担当者が抱えている問題をほとんど知らないと答えています。

これは憂慮すべき数字です。これらのストレス要因がタイムリーに対処されない場合、従業員は燃え尽き、仕事と生活のバランスを求めて退社してしまうでしょう。私たちの調査によると、回答者の23.1%が現在の会社のワークライフバランスが悪い場合、新しい仕事を探すだろうということが分かりました。熟練した担当者を新たに雇うためのコストは30万ドル以上にのぼるため、スキルの高い従業員を維持することは会社の利益のために重要です。

チームを健全に保つための洞察を得る

PagerDutyはオンコール担当者が直面する課題を認識し、企業がIT運用とオンコール担当者の健康を全体的に改善するのを支援するため、データ分析とアドバイザリー・コンサルティングを組み合わせたPagerDutyオペレーションヘルスマネジメント(OHM)サービスを開始しました。 OHMサービスは、PagerDutyの幅広い分析機能のポートフォリオの一環として、企業に最も価値のある資産、つまり人材について、実践的な洞察と助言を提供します。私たちはIT運用を人間的にし、その背後にいる人々の生活の改善に導きます。

各企業はオペレーションヘルススコアと呼ばれるスコアを使い、我々が特許出願中のアルゴリズムと機械学習、ドメインの専門知識とピアベンチマークデータを活用し、業務の健全性を定量化することができます。OHMサービスを通じて、企業は組織やプロセスの改善点を把握し、オンコール担当者とチーム、サービスの健全性を損なう問題を特定して修正することができるようになります。

チームの健康、生産性、そして幸せを向上させたいとお望みならば、今すぐ無料のオペレーション健康度アセスメントをご覧ください。

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

続きを読む
DevOps
2018年2月7日  (更新日:2022年3月9日)

Splunk インテグレーションガイドを追加しました

Splunk は、ネットワークトラフィック 、Webサーバー、カスタムアプリケーション、アプリケーションサーバー、ハイパーバイザー、GPSシステム、株式市場フィード、ソーシャルメディア、既存の構造化データベースなど、想像以上のあらゆるソースからデータを収集し、索引付けします。インテグレーションにより、Splunkのネイティブwebhookを使用してPagerDutyにアラートが送信されます。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年2月5日  (更新日:2022年3月10日)

ServiceNowエンタープライズインテグレーションガイドを追加しました

ServiceNow Enterprise は、エンタープライズ環境に高度な自動化とプロセスワークフローを提供する強力な サービスプラットフォームです。PagerDutyの堅牢なオンコールスケジューリング、通知、エスカレーションにより、ServiceNowのワークフローやチケット機能を活用することができます。 このガイドは、ServiceNow IstanbulおよびHelsinkiの認定を受けており、お客様の環境にPagerDutyをインテグレートするプロセスを案内します。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年2月5日  (更新日:2022年3月11日)

OK、Google。次のオンコールはいつだっけ?

VoiceOpsは次に進む準備が出来ている?

想像してみよう : PagerDutyからコールがあり、静かな声であなたに、注意すべき問題があるよと伝えてくれる。あなたの心中はきっと乱れ、心の声が次のように聞こえるだろう。

“げげ!これは直さなくっちゃ!”

“どうすればいい?”

“これは他人の問題かも”

…あるいはここには書けないような汚い言葉かも。

DevOpsの動きが立ち上がるということは実は、担当者は9時から5時まで個室に詰めて問題を解決するだけでは済まなくなるってことだ。 スマートフォン、ラップトップ、高速な家庭用Wi-Fiが使えるようになって、人々は自宅で仕事をすることも求められるようになった。 何かが起きれば、いつどこにいても、多数のプラットフォームを通じて通知を受け、対応できる。

でも今のテクノロジー・フォワード・ソーシャルや数多くのコミュニケーション・オプションがあるにもかかわらず、ラップトップや信頼できるWi-Fiにアクセスしないとか出来ないといったこともある。例えば通勤中や、コーヒーを飲んで会議をしているときとか、歯科医のオフィスで根管治療を受けているときとか。 こういうケースでは、声で反応するほうがより自然に感じる(根管治療中は除くけど)。

“エスカレーションしてよ。今私は答えられない。 “

“ああ分かった。確認。”

“うーん。担当者を増やすようリクエストして。データベースチームのEllenを探してくれるかい。 “

このシナリオを念頭に、われわれPagerDutyの中では、人々が実際にPagerDutyとどう話したがるかを研究し始めた。 まずPagerDutyと最も関連性の高い2つの状況を考えた。

戦闘中:多くの人々が大規模なインシデントに対応している状況で、複数のチームが絡んでいて、会議ブリッジで通信している可能性が最も高い。

小競り合い:1人の担当者が、マイナーなインシデントを確認して処理をしており、ダッシュボード、メトリック、およびランブックを参照して、一人で頑張っている。

しかしもう一つのシナリオがある:平時だ。これは、各チームが比較的静かな時間を最大限に活用してスケジュールを編集したり、分析結果を チェックしたり、サービスを設定したり、オーバーライドを管理する時間だ。 自宅の音声対応デバイスがあったら、みんなどう信頼を得るかを考えてみよう。 相互作用のほとんどは、比較的「平和」なものだ。消費者は、比較すれば緊急でないコマンドを試すことで、家庭の音声対応デバイスを信頼し始めている。

“今日は傘がいる?

“冗談を言ってみてよ”

“チーターってどのくらい速く走れるの?”

システムの状態をチェックすることは、天気をチェックするのと同じくらい自然でなければいけない。 平時のVoiceOpsは、人々がデジタルオペレーションを管理する方法を変えるはずだ。UXデザイナーのCorinna Sherman氏や、ソフトウェア技術者のZayna Shahzad氏は、平時のVoiceOpsの可能性を見出し、次にGoogle Assistant、Google Homeデバイス、そして PagerDuty APIを使ってプロトタイプを作った。

われわれはActions on Google開発者コミュニティとチームを組んで、先月共同でハックイベントを開催し、そのプロトタイプをPagerDutyコミュニティやHackbright AcademyとCode2040の出席者と共有した。

このイベントで我々は、Actions on Google AssistantとPagerDuty APIを使ってデモを作るためのブレーンストーミングを全員で実施しアイデアをひねり出した。優勝者はGoogle Homeデバイスを授与されたので、イベント後も引き続きプロジェクトに取り組める。さらに、Actions on GoogleのDevエバンジェリストであるIdo Greenが、参加者が音声を使った設計の原則を理解し、いくつかのコードラボをわたり歩き、Dialogflowでさまざまな自然言語技術を使って時間をかけて改善する方法を共有するのを支援した。

VUI Design from Ido GreenからのVUIデザイン (訳注:スライドが開きます)

学んだことは?

VoiceOpsは、 小競り合いの際のシナリオで、担当者が予定外のマイナーなインシデントの解決に独自に取り組んでいるときに、その役に立つ。

VoiceOpsは平時のマネージャーに約束しており、通常は毎日自分のチームのPagerDutyアプリケーションをチェックしない人にも答えを提供する。

VoiceOpsはまだ戦闘時に対しては準備が整っていない。Corinna氏が指摘しているように 、アクセントの認識の問題があったり、音響に問題がある部屋では、音声認識はかなりひどくなる。

音声認識と対話がうまくいけば、人々はVoiceOpsを使ってうまく働けるだろう。音声対話が設計どおりに動作しない場合、人々は不満を感じ、信頼しなくなる。

もっと学びたい?それなら プロトタイプをチェックし、コミュニティフォーラムでディスカッションに参加してください。 あなたはオンコール中に何を尋ねる?オンコール中でないときは? 私たちはそれを聞きたい。 また、PagerDutyコミュニティに参加してイベントなどの最新情報を忘れずに入手してください。

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

続きを読む
DevOps
2018年2月1日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Slackインテグレーションガイドを追加しました

Slackは、組織がさまざまなサービスを単一の通信プラットフォームに結びつけるために使用できる強力なチャットツールです。Slackはあなたのチームのコミュニケーションを容易にします。Slackとの統合により、Slack内からPagerDutyインシデントを認識し解決することができます。これはSlackスラッシュコマンドインテグレーションガイドを補完するもので、古いSlackインテグレーションガイドに代わるものです。

詳しくはこちら

2018年1月30日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Nagios 2-wayインテグレーションガイドを追加しました

Nagiosは、エンタープライズ規模に対応した、オープンソースのITインフラ監視ツールです。Nagiosは世界中の何十万人ものユーザーに使われており、ITインフラ全体を監視し、問題が発生する前に発見し、セキュリティ違反を検出し、ITアップグレードの計画や予算を立てるために利用できます。インストールが簡単な当社製のエージェントを使って、Nagios 2、3、4をPagerDutyとインテグレーションする方法について説明します。

詳しくはこちら

2018年1月25日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Slackスラッシュコマンドインテグレーションガイドを追加しました

Slack は、組織がさまざまなサービスを単一の通信プラットフォームに結びつけるために使える強力なチャットツールです。Slackはあなたのチームのコミュニケーションを容易にします。 このインテグレーションにより、SlackのPagerDutyでインシデントをトリガーすることができます。 これはPagerDutyインシデントに関する情報をSlackチャンネルに投稿するPagerDuty to Slack統合を補完します。

詳しくはこちら

2018年1月23日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

JIRAのインストレーションガイドを追加しました

JIRA Software は、組織内のチーム間のコラボレーションを可能にするプロジェクト管理ツールです。 このガイドでは、JIRA で作成された新しい問題がPagerDutyで新しいインシデントを作成し、JIRA で「完了」という問題をPagerDutyで解決するように、JIRAとPagerDutyを設定するプロセスについて説明します。

詳しくはこちら

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文化を受け入れる組織は、ソフトウェア配信をよりシームレスにして、最先端の開発の実践をより成功させるでしょう。

2018年1月22日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Zabbixのインストレーションガイドを追加しました

Zabbix は、ネットワークサービス、サーバ、およびその他のハードウェアのステータス を監視するために設計された、非常に強力なオープンソースのエンタープライズクラスのネットワーク管理システムです。多くの組織のITインフラストラクチャを監視する上で重要な役割を果たしています。 このガイドでは、インストール済みのZabbix 1.xまたはZabbix 2.x環境を、PagerDutyにPythonスクリプトを使って統合する方法について説明します。

このガイドでは、Zabbixの中でスクリプト、メディアタイプ、ユーザ、アクションを設定する方法を説明します。LinuxディストリビューションのバージョンとZabbixの設定によってはそれに合わせて、下記の手順を少し変える必要があるかもしれません。

詳しくはこちら

2018年1月20日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Mackerel.ioのインストレーションガイドを追加しました

Mackerelは、エレガントでシンプルで使いやすいサービスで、ロールの概念を使用してホストを監視および管理します。ホスト上でmackerel-agentというプログラムを実行することで、Web上またはAPI経由で複数のホストを管理するだけでなく、ホストやアプリケーションの状況を高度にカスタマイズした形で可視化できます。

Mackerel.ioで生成されたアラートは、PagerDutyでインシデントをトリガーし、SMS、電話、電子メール、またはプッシュ通知を介して適切な技術者にアラートを送ります。以下のガイドでは、インストール済みのMackerelとPagerDutyをインテグレートする方法について説明します。

詳しくはこちら

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月18日  (更新日:2022年3月9日)    |    DevOps

DevOps:開発者の視点から

「オペレーションルームに歩いて行く – もうこれ以上何もする必要はないと思う」

開発者のための最新の機能のリリース(訳注:英語サイトに飛びます)で、PagerDutyのシニアエンジニアDavid Yang氏と私は、私たちの内部アーキテクチャが単一のモノリシックなコードベースから数十のマイクロサービスの組み合わせにまで進化していくのを見てきました。

彼は、8000人以上のPagerDutyの全顧客にアラート通知を送信するサービスを所管するIncident Management – Peopleチームのテクニカルリーダーです。私たちは座って、彼らのサービスの運用について彼のチームがオーナーになるよう切り替えた後の生活について話しました。 私たちが見た利点と欠点に関するいくつかの観察を紹介します。

今はチームがサービスのオーナーになっています

開発者がサービスのオーナーになるモデルに移行して以来、開発者の独立性はますます高まっています。副作用は、インフラストラクチャのプロビジョニングと管理の難しさを最小限に抑えられたことです。現在、チームは邪魔と障害を最小化するように最適化したいと考えています。 インフラをサポートするチームは、人間の介入の必要性を最小限に抑えるために優れたセルフサービスツールを提供することに重点を置いています。

開発者がコードのオーナーになると、サイクルタイム、つまり「これは問題だ」というメッセージがどこかで表示されてから実際に問題を解決するまでの時間が短縮されます。これは非常に価値があります。

文化面での変化は

人々がより多くのコードのオーナーになり、自分たちが運営するシステムのために一般的にはより多くの責任を負うようになると、道を邪魔するものを排除することを重視する文化が広がります。各チームは、 「自分が今まで、あるいは将来ブロックされていないことを確認するにはどうするか」という考え方に向かって最適化されます。ブロックされるともっとはっきり分かります。以前は、ホストをプロビジョニングするたびに私は毎回運用チームに問い合わせなければなりませんでした。 私のチームは他のチームの障害物で隠されていないため、自分たちの障害物をよりはっきり見ることができます。

私たちには、エンドツーエンドの顧客価値を提供するプロセスのすべてを所有することに重点を置いたチームがあります。これは非常に貴重です。

インシデント対応プロセスではどうに役立つ?

サービスのオーナーシップの境界が明確になっています。運用の問題が発生した場合に、影響を受けるチームを簡単に特定できます。そして、自分が従うべき正しい手順、例えばそれは「これがそのチェックリストです」という客観的な手順ですが、それを知っているということが大事です。 これによって問題の解決に100%集中し、インシデント前後のコミュニケーションに集中することができます。

それほどうまくいかなかったことも

サービスのオーナーになっていても、そのサービスに問題が発生しないとは限りません。当社のサービスの運用維持に専念するためには、そのためだけに使う時間が必要です。 これが結局はチームの時間の多くを占めます。特に知識のギャップがあるレガシーサービスで問題になります。 当初は、私たちのスプリントでの作業性を守るために十分なガードレールを設置していませんでした。 これは客観的な意思決定を可能にするためにKPI(特定のスケーリング目標や運用負荷レベルなど)を活用することで改善されています。

将来は?

[業務関連のワークロードと機能開発ワークのバランスをとるため]各チームは、メトリックによって客観的な意思決定を推進するために、次のように問い続けています。「私はこうした道具を日常的にどう活用していますか? どのようにして客観的な意思決定を行うのですか?」と。

組織内の業務の中で変更を実行しようとすると、多くのコラボレーションが必要になります。 適切なメトリックが何であるかを把握し、それらのメトリックについて議論することも必要です。

2018年1月18日  (更新日:2022年3月10日)    |    インシデント&アラート

インシデント管理データで技術的負債を測る

技術的負債(technical debt)が借金のようなものだったら、手作業でチェックインしない限り、それを追跡するのは難しいでしょう。 多くの人にとっては自分の当座預金口座に資金がなくなったことを知る唯一の方法は、口座の残高を確認することです。さらに悪くなると、小切手が返されたり、デビットカードが拒否されます。

しかし、技術的負債の測定はもっと自動化できます。 これは、お客様の銀行口座とは違って、ITインフラストラクチャの場合はそれを専用のツールで継続的に監視でき、重要なヘルスメトリックについて通知を受けることができるからです。 次に、監視データを使い技術的負債についての情報を得ることができます。 つまり、データセンターで問題が発生したときに手動で監査する必要はありません。 問題があることを知るのに、サーバーがダウンするまで待つ必要はありません。 インシデント管理ツールは、その情報を提供します。 エクステンションを使えば手作業で面倒なことを測定することなく、技術的負債を取り込む方法も提供しています。

インシデント管理は、技術的負債を追跡して修正するのに役立ちます。追加の投資は必要ありません。

技術的負債の定義

まず、技術的負債の意味を説明しましょう。 技術的負債とは、長期的には非効率性やその他の問題を引き起こすような、ソフトウェアコードやアーキテクチャの不完全性を指します。 たとえ欠陥自体が小さいとしても、その効果が継続的に繰り返されるため、時間の経過とともに多くの利子が生じることがあります。

例えば、モジュラーアプローチを採用しておらず、同じ機能の複数のバージョンをコードに含むようなプログラムは、より優れたプログラムよりも実行に数ミリ秒余計にかかることがあります。 一度だけそれを実行するなら、大きな問題にはなりません。 しかし、それがサーバーの側で1日に数千回実行されるWebアプリケーションであれば、パフォーマンスが低下したり、CPU時間が浪費されたりするという負債があっという間に積み上がります。

技術的負債には多くの潜在的な原因(訳注:クリックすると英語版のWikiに飛びます)があります。 場合によっては、例えば何かを迅速に導入しなければならず、ベストプラクティスに従う時間がない場合は、負債がコストに見合う価値があると判断(少なくともその時点で)して、技術的負債を意図的に負うことがあります。管理者の中で最も優れた人でも将来の技術的負債を避けることは難しいです。 将来を見通せない限りは(例えば、あなたがアップグレードする余裕がないために今日も使用している10年前のスイッチが、最新のファイアウォールツールではうまく機能しないということは過去の時点では分からなかったはずです)。 その場合、技術的負債は、不完全な世界での生活で起きることまったく同じ経緯をたどります。

技術的負債を追跡する

技術的負債には多くの源がありますが、それをインシデント管理を使用して測定するというアプローチは、問題の原因を問わず問題の追跡を容易にします。繰り返しますが、時間のかかる手動のシステム監査で非効率性を検索する代わりに、インシデント管理データを技術的な負債の程度を評価し、それを評価するためのプロキシとして活用できます。

やり方を理解するために、PagerDutyが追跡するさまざまな種類のインシデント管理データの例と、それらのデータが技術的負債について明らかにできることをいくつか見てみましょう。

まず、ツールが生成するアラートの生の数を取得します。これは非常に基本的な指標であり、さまざまな要因によって影響を受ける可能性があります。しかし、インシデント管理の報告システムが適切に構成されており、インフラストラクチャに大きな変更を加えなくてよいと仮定すると、技術的負債の規模とツールが報告するインシデントの数との間に相関が見られる可能性があります。負債が増えるとパフォーマンスが低下し、応答時間やリソースレベルが特定のしきい値に達するとアラートがトリガーされるためです。したがってアラートの発生率が月ごとに減っていれば、コードがより効率的になったので技術的負債が減っている可能性があります。

平均解決時間(MTTR)は、技術的負債を見るためのインシデント管理の指標です。MTTRが悪い一般的な原因の1つは、コードがあまりにも複雑すぎることです。例えば、上の例を再利用するために、急いで書かれたコードには冗長な機能が含まれているため、管理者にはすぐに理解するのが難しいでしょう。これは、事件に対応するためにコードを読み込んで変更する必要がある場合に、解決時間が長くなることを意味します。

技術的負債の源を見つける

インシデント管理データは、技術的な負債に関する一般的な傾向を追跡するのに役立つだけでなく、問題の原因をゼロにするのにも便利です。

たとえば、特定のプログラムに関連するインシデントのMTTRが平均MTTRよりも高い場合、問題のプログラムが技術的な負債を生成している可能性があります。同様に、あるタイプのオペレーティングシステムを実行しているサーバーが不均衡なアラート数の大部分を占めている場合、おそらくコードまたは構成上の欠陥があります。それはあなたが対処できる技術的な負債です。

インシデント管理データを使って技術的負債を特定し、対処するのはとてもクールで、ほとんど追加作業を必要としません。あなたは既にPagerDutyのような操作と報告を集中化するハブ(うまく設定すればですが)を備えた監視システムを備えています。これらのリソースを活用して技術的負債を見つけて修正するには、追加のツールや投資を必要としません。既存のソフトウェアを使用して、コードや操作をより効率的にすることができます。

2018年1月17日  (更新日:2022年3月11日)    |    DevOps

DevOpsの失敗から学ぶ方法

DevOpsの失敗は微妙な話題です。それが一般的にはDevOpsは障害を回避する方法として認識されているからです。その結果、DevOpsの実践に失敗した場合、状況はほとんど絶望的に見えます。しかし、フェイルファーストのビジネスアプローチや、「失敗して早く修正する」アジャイルの手法がしばしば証明するように、DevOpsの失敗は実は正しい方向への一歩なのです。失敗から学び、DevOpsの実践を、後まわしではなく早く、より大きな成功に導く道に向かわせるための第一歩です。

DevOpsはアジャイルに発するものです。頻繁なフィードバックループで開発サイクルを短くすると、顧客のニーズに一層合致した製品の提供に集中できます。フィードバックループの活用ポイントは、顧客からのフィードバックを通じて行動から学び、何が正しいのか、何が改善できるのかを測定することです。

フィードバックループは、頻繁な変更と失敗からリスクを実際に減らすよう学べる機会を提供するため、効果的です。DevOpsの実践に打撃を与える失敗はいろいろなので、それにどう対応するかが重要です。ではいくつかを細かく見てみましょう。

インシデント対応の失敗

ソフトウェア関連の問題が発生した場合(ソフトの展開に関連することであろうとバグであろうと)、それが起きたという事実よりも、どう反応したかがたいていは重要になります。 ここでの失敗は、以下を含む複数の形で発生する可能性があります。

過剰反応**:障害からの回復や、失敗の繰り返しを避けるために、過度の時間を費やしたり、過度に多くのリソースを費やしたりすることです。

誤った反応**:情報の欠如による問題の誤診や、問題の見積もりを誤ること。

無反応**:問題を早急に修正したり、効果的に修正したりするのを忘れ、直後に問題が再発すること。

インシデント管理とKPIによる成功を評価することは、DevOpsの成功の要件である測定の重要な部分です。関連する情報を浮上させ、他のチームメンバーを募集し、個々のコンポーネント(およびそれらの背後にある人)を原因として示すのではなく、全体としてシステムを見て、インシデントを迅速に評価して解決します。

ここでの取り組みには、インシデント対応、知識の伝播、将来の問題を回避するための過去のインシデントからの学習、問題解決の自動化による迅速な対応といったことが含まれます。

プロセスの作り過ぎ

DevOpsは単なるプロセスまたはツールであると考えて、厳格で正式な一連の手順を設定することをに走る人もいます。しかし、あまりにも多くのプロセスを作ったり、プロセスについて厳格すぎたり、特定のツールセットを強制すると、組織の柔軟性が失われる可能性があります。 そうではなく、DevOpsには、組織の敏捷さを向上させるツールと手順が含まれている必要があります。

例えば、ソフトウェア開発と展開の効率の全体を測定するツールは、その効率を向上させるためのフィードバックを提供するのに役立ちます。 どうやって? 変更が必要な箇所と削除する必要のあるボトルネックを指摘するのです。厳格になりすぎると、変化するユーザーベースまたは市場のニーズを改善または満たすために迅速に変えられなくなる場合があります。

DevOpsの範囲を制限する

DevOpsの実践の仕事は、組織内の一人の人間やチームだけには任せられません。 私は、既存のソフトウェア展開とメンテナンスの問題をすべて修正するためにある人が”DevOps Person”として特別に雇われ、”DevOps stuff”を魔法のように行う状況を目撃しました。しかし、そこには足りない点がありました、「そのアプローチが失敗する」と考えなかったことです。

同様に、顧客サービスおよびサポート担当者が、事前に知らされていなかった、週末にインストールされた新機能に関してコールを受けた状況も見てきました。 主なサポート担当者がお客様からソフトウェアの変更を知らされるような場合は、DevOpsの失敗が起きます。

DevOpsは、アジャイル開発から学んだことを取り入れ、ソフトウェアの展開全体を通じてエンドツーエンドで適用する、構成的な実践方法です。 これはビジネス全体の他の機能にも拡張する必要があります。 つまり、開発作業は各プロジェクトではなく顧客への価値に沿って行われ、製品チームはITスタッフとだけではなく、コールに対応する人や、技術文書を作成する人、アプリケーションを宣伝して販売する人、ビジネススポンサーとして働く人たちとも共に働かなくてはなりません。その中には将来計画を立案するエグゼクティブも含まれます。 フィードバックループを拡大して組織の全員を構成するには、誰もが覚えておくべきことがあります。

ここでは、フィードバックループ、コミュニケーション、および主要な測定活動を組織のすべての部分に拡大することを含みます。 また、サードパーティベンダー、サプライヤー、コンポーネントを除外しないでください。 外部コンポーネントの検証、監査、および監視も含めてください。

不毛な責任追及と競争を回避する

アジャイルは、組織のソフトウェア配信パイプラインでのボトルネックを明らかにすることが多く、物事を遅らせていると思われる人や活動を指摘するのは簡単です。これが起きると、DevOpsは意図していたのとは正反対に、チーム間をばらばらに引き裂くくさびを打ち込むことになってしまいます。

そうではなく、サイロ(真空中で仕事をしようとするチームや人)を取り除き、ボトルネックや改善を特定するよりも先にチーム間の壁を壊してください。 全員が最初に協力して責任を共有することで、チーム同士が競争する結果ではなく、1つにまとまるという改善ができます。

サイロを徹底的に排除する

組織内で例外を作っていることは珍しいことではありません。 たとえAgileやDevOpsで実際に成功を収めている組織でもあることです。おそらく、それはレガシーなアプリケーションや、過去に実績があるチーム、またはベテランの従業員です。 しかし、DevOpsの実践から個人やチームを除外するのは面倒な作業です。

サイロは、組織のソフトウェア展開の実践を複雑化して毒になる可能性があります。 そのサイロに共同創業者が含まれていたとしても、組織のDevOpsが奨励するプロセスとコラボレーションから免除されるべきではありません。 一言で言えば、DevOpsはサイロとボトルネックを取り除くことを意味します。例外なしに。

開発環境を無視する DevOpsは、本番環境と展開するもの以外にも適用されます。 アジャイル開発のスプリントが成功し、本番環境の導入が自動化され、テストが継続的に行われている場合でも、開発環境にこれらの実践を拡張しないと、独自の問題が発生します。たとえば、開発環境とテスト環境が同じツール、アプローチを使っておらず、その運用環境を管理する担当者によって管理されてもいない場合、ソフトウェアが想定外のユニークな構成に初めて遭遇したときに生産上の問題が発生します。

チームからのアクセスをむやみに増やさない DevOpsの結果としてチームワークが強化されるのは良いことです。またソフトウェアの開発過程で、新しい手順やコンポーネントにさらされるにつれ、チームメンバーが成長する能力も向上します。 しかし、これに伴う責任の追加分担を忘れると、重大な失敗につながる可能性があります。 たとえば、DevOpsはUI開発者がアプリケーションのデータベースに慣れるのに役立つかもしれませんが、UI開発者がDBの変更を自分で公開する権限を持つようになると、誤って本番データベースを変更するといった事態も起こるかもしれません。 ボトルネックは除去すするにしても、大災害を避けるためにコントロールも必要です。

重要なプロダクションシステムへの予期しないアクセスを監視して報告し、意図しない変更をロールバックする(またはロールフォワードする)手順を導入するべきです。

結論:つまりは人の問題です

ゴールはDevOps自体の成功ではありません。プロセスでも活動でもありません。ゴールはソフトウェアとカスタマーエクスペリエンスと組織を改善するためにDevOpsの使命をまっとうすることです。 これらのいずれかが欠落している場合は、DevOpsで成功していると思っても生きるのは難しくなるかもしれません。

これまで説明したことすべてに現実の人々を巻き込むよう肝に命じること、それが重要です。 DevOpsがどう役立つかに関係なく、失敗から学び、絶えず改善を続ける文化を吹き込み、顧客を幸せにし、楽しい時を過すことが本当に大切です。 あなた自身のゴールを達成するために働く毎日の中で、本当に大事なことを忘れないでください。

2018年1月15日  (更新日:2022年5月19日)    |    インシデント&アラート

アラート管理:インシデントの優先順位をどう決めるか

アラート 。それはいとも簡単に積み上がります 。一瞬で目にするアラートはほんの一握り。でも数時間、場合によっては数分後に、積みあがった山を見ることになります。 どのようにそれらを管理すれば、担当者がお手上げにならないようになるんでしょうか?

これらは非常に重要な質問です。 アラート管理システムにノイズが溢れていて、対応チームが慢性の疲労状態にある場合は、初動に対応するITアラート管理システムを持っていないも同然です。 過剰なノイズとアラート疲れは、アラート管理システムの有効性を完全に低下させます。

フィルタリングの適用:インシデントにアラートをまとめる

多くの点で、アラート管理システムの合理化の鍵は、関連するアラートをインシデントに統合し、インシデントの優先順位を決定するための迅速かつ正確な方法にあります。緊急度別にインシデントを並べ替えることで、ほとんどのノイズを自動でフィルタすることができ、すぐに注意が必要なものとしばらく様子を見ることができるものを、合理的に推量することができます。すべてのアラートがインシデント化や対応を必要とするわけではありません。対応不要なアラートを抑制すると、ノイズがさらに削減され、重要なことに集中できます。

ソート(優先度順に並べ替える)プロセスの一部を自動化する(例えば、ソースとキーワードで並べ替える)ことはおそらく可能ですが、一部の(多分相当な量の)ソートプロセスでは、ディスパッチャの役割を果たしているレスポンスチームの誰かが介在する必要があります。ただし、どのような方法を使用しても、基本となる基準は変わりません。

優先順付けのスキームのほとんどは、ITILが定めているインシデントの優先順位付けガイドラインなどに準拠しています。インシデントの優先順位は、インパクトと緊急性という2つの密接に関連する要因に基づいて付けられます。この記事では、これらの要因とその相互作用について詳しく見ていきます。

インシデントのインパクトを判断する

インパクトは、インシデントの影響範囲(部門、ユーザー、または主要サービスがどれだけ影響を受けるか)に基づきます。 影響判定プロセスの少なくともいくつかの要素を自動化するのは比較的簡単です。 たとえば、ほぼ同時に特定のサービスが利用できないことを示す多数のレポートが出てくれば、影響の大きいインシデントになる可能性があります。一方、単一のユーザーからの問題のレポートは、類似のレポートが他になければ、 影響の少ないインシデントだということを示します。 多くのIT部門にとって、インシデントの影響を判断するためのガイドラインは、次のようになります。

高インパクト

重要なシステムがダウンしている。 1つ以上の部門が影響を受ける。 相当数のスタッフがその機能を実行できない。 そのインシデントが多数の顧客に影響を与える。 そのインシデントが、財務上の大きな損失や組織の評判への損害になる可能性がある。 組織の機能と影響を受ける他のシステムに応じて変わるその他の基準もあります。例えば公衆の安全上の脅威、人命の喪失、または重大な財産の被害などが含まれる可能性があります。

中程度のインパクト

一部のスタッフまたは顧客は影響を受ける。 失われたサービスはどれも重要ではない。 財務上の損失や組織の評判への損害は起きる可能性があるが、範囲は限られている。 人命、公共安全、身体的財産への脅威がない。

低インパクト

少数のユーザーしか影響を受けない。 重要なサービスは関与しておらず、財務上の損失や評判の低下の可能性はほとんどない。

インシデントの緊急度

インシデントのインパクトとその緊急性を厳密に区別することは必ずしも容易ではありませんが、ほとんどの場合、このコンテキストで言う「緊急性」とは、「問題がシステムにどれだけ早く影響を及ぼし始めるか」ということだと定義できます。 給与計算システムの故障は、例えば、影響が大きい可能性がありますが、給与の支払い周期の始めに発生した場合は、毎日使う顧客関係データベースの損失よりも緊急性が低い可能性があります。

緊急度高

日々の操作に不可欠なサービスが利用できない。 インシデントのインパクトの範囲が急速に拡大しているか、または迅速なアクションによってその範囲を制限できる可能性がある。 時間に敏感な仕事や顧客の行動に影響がある。 そのインシデントが、高位の個人または組織(上級管理職または主要なクライアント)に影響を与える。

緊急度低

影響を受けるサービスはオプションであり、まれにしか使用されない。 インシデントの影響は拡大しないように見える。 重要な作業や時間に敏感な作業は影響を受けない。

注意してほしいのは、インパクトと緊急度の両方について、一般的には各カテゴリの1つの基準に当てはまればそのカテゴリになると思ってよいということです(基準のすべてまたは大多数を満たす必要はありません)。インシデントは、それが条件を満たす最も高いカテゴリに配置する必要があります。

優先度=インパクト+緊急度

以上のように考えれば、優先順位をインパクトと緊急性の両方の合算で評価すべきだと分かりやすくなったはずです。アラート管理とインシデントのディスパッチプロセスには関係なく、優先順位を決定するための基準に従ってルーティングする必要があり、結果としてアラートノイズを大幅に減らすことができ、低インパクト、低緊急度のイベントは自然に優先順位リストの下端に並ぶと思います。これにより、インシデント対応チームは、非常に注意を払う必要がある、高インパクトで高優先度のインシデントに集中することができます。

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