NOC（ネットワークオペレーションセンター）のプロセスは、何十年もの間、定石とされてきました。しかし、これらのプロセスの一部は、そろそろ進化する時期にきています。DXとクラウド時代の到来により、DevOpsが台頭し、それに伴いサービスオーナーシップも台頭してきました。サービスオーナーシップとは、とは、開発者が自分たちが提供するソフトウェアをライフサイクルのあらゆる段階でサポートする責任を負うことを意味します。これにより、開発チームは顧客やビジネス、そして提供する価値により近い存在となります。
また、従来のNOCのインシデント処理方法からの脱却も必要です。しかし、組織がサービスオーナーシップに移行するにつれ、古いNOCのプロセスがいくつか残っています。ここでは、3つの一般的なNOCプロセスの後遺症と、それらを置換、または更新する方法について説明します。
プロセスの後遺症：L1レスポンダーが問題を解決できない
かつてNOCは、技術的な問題の司令塔でした。NOCは脳のように機能し、関連する付属機器に信号を送るのです。ネットワークに問題があったら？ネットワークへのルート。セキュリティーの問題があったら？セキュリティーへのルート。NOCの中心的な役割は、問題を解決するために適切な専門家を関与させることでした。これは、誰が何を担当しているかを把握するために、スプレッドシート（時には物理的な連絡帳も！）を掘り起こすことを意味します。
全てがオンプレミスで対面式だった時代には、これは理にかなっていました。サービスも少なく、インシデントも部署ごとにきちんと分けることができました。もしデータベースに問題があれば、データベースのオンコールレスポンダーを呼び出すことができます。そのレスポンダー（おそらくオフィスにいるか、直接対応できるほど近くにいる人）は、データセンターに行き、調べることができました。 しかし、リモートワークやクラウドの時代には、世界中に散らばる数十、数百のチームによって数百、数千のサービスが管理されており、メモカードの束方式はもはや用済みになっています。どのチームがどのサービスを担当しているのか、正確なスプレッドシートを維持することは不可能に近いのです。また、組織が変われば、記録はすぐに古くなります。サービスはチーム間で流動します。チーム間の移動や、退職・入社に伴い、チームも変化します。L1レスポンダーは、効率的かつタイムリーに適切な担当者を特定するために、大変な努力をしなければならないのです。 組織は、適切な担当者を見つけるためのこうした手作業のステップを排除し、あらゆる問題に飛び込んで対応できる専門家に直接インシデントを転送する方法を必要としているのです。これは、さまざまな方法で実現できます。一部の組織では、DevOpsサービス所有権モデルが正しい道筋となります。コードを書く人は、インシデント発生時にサービスに対応し、修正するよう割り当てられます。アラートは、サービスをサポートする開発チームのオンコール担当者に直接送られ、そこから専門家が対応します。 他の組織では、L1レスポンダーが防御の第一線として機能した後に、分散したオンカルのチームにエスカレーションしてサービスを提供するというハイブリッドアプローチが理にかなっている場合もあります。L1レスポンダーは、問題を他のチームに接続するルーティングセンターであってはなりません。その代わりに、インシデントを自ら解決する権限を与える必要があります。L1レスポンダーに、トラブルシューティングとインシデントの選択的解決の両方の能力を与えることで、より効果的にL1レスポンダーをセットアップすることができます。自動化とランブックのようなリソースにアクセスすることで、L1レスポンダーは診断と修復のプロセスを加速させることができます。L1 レスポンダーに自動化を導入することで、組織は不必要なエスカレーションを回避し、L1 が問題を迅速に解決できるようになります。
プロセスの後遺症：重大インシデントで呼び出しをしない、または呼び出しが遅すぎる
「時は金なり」という言葉を聞いたことがあるでしょう。インシデントに確実に対応するための主要な方法がNOCであったとき、NOCは多くの責任を負っていました。NOCは、リソースが適切に管理されていることを確認する必要がありました。これは、問題に対応する不必要な人物がいないことを意味します。NOCは、重大なインシデントで担当者を早く呼び出したり、微細な問題で人々を中断させたりすると、しばしば非難を浴びていました。このような混乱は、専門家を技術革新のための仕事から遠ざけてしまうことになります。そのため、NOCのレスポンダーは、より大きな問題が起きていることが明らかな場合にのみ、担当者を呼び出すことが極めて重要だったのです。
しかし、今は「時は金なり」ではなく、「稼働時間は金なり」なのです。大規模な事故が発生した場合のコストは、追加で人員を投入する場合のコストよりも大きくなります。例えば、オンラインショップでショッピングカートの機能がダウンしたとします。お客様が商品をカートに入れられない分、何十万ドルもの損失を被ることになります。さらに、ここ数年で、顧客の期待は高まっています。お客様は、アプリ、ツール、プラットフォーム、ストリーミングサービスなどが中断することなく機能することを期待しています。そして、そうでない場合は、顧客の信頼を損なうことになります。実際、PWCによると、３人に１人の顧客が、気に入っていたブランドで1度でも悪い経験をしたら、そのブランドとの取引をやめると回答しています。
各組織は、顧客への影響を軽減するために、重大なインシデントをより早く伝える必要があります。確かに、これは、不必要に誰かを起こすことを意味するかもしれません。しかし、サービスのオーナーシップがあれば、その可能性ははるかに低くなります。サービスを担当する専門家は、L1レスポンダーよりも、いつ重大インシデントの呼び出しをすべきかを理解しています。そのため、誤報が少なくなるのです。
プロセスの後遺症：出入りの激しいウォールーム
NOCは、しばしば大規模なインシデントのコミュニケーションハブとして機能します。これは、問題解決に取り組む対応者が作業を継続するのに役立ちます。多くの企業が全てを（そして全ての人を）オンプレミスで管理していた時代には、ウォールームがありました。人々はそこに集まり、NOCコーディネーターは皆に最新情報を提供しました。現在では、チームやシステムが分散しているため、物理的なウォールームは過去のものとなっています。多くの企業は代わりに、ビデオ会議ブリッジやチャットチャンネルを備えた仮想ウォールームも持ち、インシデント発生中もオープンにしています。
他のステークホルダーは、このウォールームを物理的な部屋と同じように扱い、好きなように立ち寄りたいかもしれません。しかし、この仮想世界では、これらの利害関係者がインシデント対応者に質問をすることになります。これでは解決は遅れます。出入りの激しいバーチャルウォールームを持つ企業では、ミスコミュニケーションやフラストレーションがより多く発生する可能性があります。対応者は中断されることにフラストレーションを感じ、利害関係者はコミュニケーションの欠如にフラストレーションを感じるのです。
これを軽減する方法の1つは、ウォールームを参加者以外には閉鎖することです。もし誰かがインシデント対応チームの一員でないなら、対応チームの仮想ウォールームにアクセスする必要はないでしょう。その代わりに必要なのは、内部の連絡役です。これは、インシデント対応チームから指名されたコミュニケーターのことです。
社内コミュニケーションリエゾンは、インシデント情報を集約し、関連するステークホルダーに伝達します。これを容易にするために、コミュニケーション担当者は、ステータスアップデートの通知テンプレートを使用することができます。このテンプレートは、特定の対象者に向けたコミュニケーションを取る方法を決定づけるものです。これにより、ステークホルダーは意思決定に必要な全ての情報を受け取ることができます。また、レスポンダーは、最新情報を共有するために、目の前のインシデントに対する作業を中断する必要はありません。
後遺症は楽しいものではないが、必ず終わる
NOCは、多くの組織でインシデントを管理するために試行錯誤されている方法です。しかし、このデジタルトランスフォーメーションの時代に移行すると、NOCの方法は時代遅れになります。シームレスなコミュニケーションと迅速な対応は、お客様の信頼を維持するための鍵です。今後、チームに担当者を入れ、重大なインシデントに早急に対応することになるでしょう。また、インシデント発生中は主要なステークホルダーとコミュニケーションをとり、境界線を設定することになるでしょう。
多くの場合、チームはこの移行をサポートするためのデジタルオペレーションプラットフォームを必要としています。PagerDutyは、重大インシデントのベストプラクティスを組織に導入し、重要インシデントを迅速に解決し、将来の発生を防止することを可能にします。14日間無料でお試しいただけます。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：DevOps
