Blog
ブログ

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人ではないことを思い出させてくれます。

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

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

メールでのアラートをやめたほうがいい5つの理由

メールアラートを改善したいですか? もう一度考えてみましょう

監視システムは、稼働中のシステムをより効果的に管理するのに役立ちます。しかし、早期に問題を特定するためにチェックとしきい値を設定するのに多くの時間を費やしたとしても、アラート自体にはインシデント対応プロセスと同じくらいの意味しかありません。 PagerDutyがお客様の声を聞いてきた中で発見した最大の課題の1つは、どのお客様もメールアラートに悩まされているということです。 受信トレイがぐちゃぐちゃになって大切なものを見逃してしまいがちだと気づいていながらもなお、多くの監視システムとIT運用チームはメールアラートに依存しています。 メールアラートを改善しようとしていますか? もう一度考えみてください。それでもまだこのまま使い続けようとお考えのあなたに、メールによるアラートをやめてしまった方がいい理由を5つお教えしましょう。

  1. メールアラートは見過ごされやすぎる

「ねえ、友達が私にメールで送った最新の猫のビデオを見ましたか?」

受信トレイを常に見ていても、重大なアラートが他のアラートや仕事関連のメールに紛れてしまうのは日常茶飯事です。 このため、優れたオペレーションチームは、通常、少なくとも2つの通知チャネルを使用します。ひとつは、電話またはSMSメッセージです。 音でアラートを知らせることは間違いなく気づくのに役立ちます。

  1. メールで誰かを確実にアサインすることはできません

「えーと、この件誰か対応してる?」

深刻なインシデントへの対応では時間が重要であり、チームの誰が対応に当たることになるのかで混乱している場合ではありません。アラートが複数の人にメールで送信されている場合、チームの誰が最初に応答するかを知る方法はありません。 他の誰かが既にそのメールを見て対応しているのか、自分はそのアラートに対応するのに最も相応しいのか、それとももっと経験豊富な人を待つべきだろうか。 優秀なオペレーションチームは、各インシデントが最適な担当者に自動的に割り当てられるようにします。 インシデント管理ツールとチケットシステムは、オンコールのエンジニアを自動的に割り当て、割り当てたエンジニアのステータスを追跡することにより、このワークフローを実行させます。

PagerDutyではオンコールのスケジュールに従い、すぐに対応に当たる人を決定してインシデントを割り当てます。

  1. メールを集約またはバンドルすることはできません。

「これ、止められないのか?」

アラートの嵐が吹き荒れる。スタッフが対応を誤ると、すべての監視システムが毎分何度もアラートを送信します。膨大なアラートは受信トレイをたちまちあふれさせて、事実上使用できなくなります。 PagerDutyでは単一インシデントのアラートは1つに集約し、複数インシデントのアラートは、それぞれの最初の通知の後にまとめて通知します。したがって担当者が受け取るアラートは一度だけです。また、ダッシュボードにより現在進行中のインシデントの数とその出所を簡単に把握することもできます。

  1. メールは状況を可視化してくれません

「現在のステータスはどうなってるんだ?」

メールでは、誰がインシデントに対処しているのか、経過時間、最新の状況の把握などは難しいです。この情報はチームだけでなく、経営幹部やその他のビジネス関係者にも重要です。あなたが対応している最中に、状況を知りたい人々に絶えず質問されるのも迷惑です。インシデントをPagerDutyのようなシステムに取り込むことで、管理者だけでなくチーム全員がアクセスできる単一のダッシュボードですべての情報を取得できます。 CEOやCTOがこれで問い合わせを控えてくれるとは限りませんが、少なくとも自分で情報を入手できる方法を伝えることはできます。

  1. メールアラートでメトリクスを作成することはできません

「僕ら、うまくやれてる?」

優れたオペレーションチームは、パフォーマンスを継続的に測定、評価、改善するためにメトリクストラッキングを採用しています。全てのメトリクスをメールからトラッキングすることは非常に困難です。インシデントが発生した時刻、最初の人が気付いて応答するまでの時間、チームが解決するまでの時間などをトラッキングすることは、完了予想時刻を管理する上で大切になってきます。このデータを使用して作成したチームのパフォーマンスを示すダッシュボードと週ごとのレポートで、チームや企業内のコミュニケーションを容易にすることができます。

メールアラートの問題は、今まさにあなたが直面している課題かもしれませんが、それはあなただけの問題ではありません。

続きを読む
インシデント&アラート
2017年12月30日  (更新日:2022年3月9日)

アラート管理プロセスの最適化

シンプルな 世界では、すべてのアラートは等しく発行され、インフラストラクチャは 完全に機能しているか、完全に壊れているかのどちらかで、その中間はありません。

しかし、実際には、世界はそれほど単純ではありません。インフラストラクチャがこれまで以上に多様で複雑な今日は特にそうです。

その複雑さに対処するには、監視とアラート管理に異なるアプローチが必要です。やって来るアラートに順番に応答するプロセスとして、またはすべてのアラートがアクションを必要とすると仮定して処理するよりもはるかに多くのことを要求されます。

この記事では、アラート管理に対する柔軟で微妙なアプローチが不可欠である理由と、その実装方法について説明します。

複雑化した現代のインフラ

柔軟なアラート管理プロセスが不可欠な理由を理解するために、現代のインフラストラクチャを複雑にする要因を検討してみましょう。次の点を考えてください。

階層化され相互依存しているインフラストラクチャ

以前はベアメタルのサーバとワークステーションがたくさんありました。今日、すべてがソフトウェアで定義される時代に、インフラストラクチャは物理マシンと仮想マシン、ソフトウェア定義のネットワーク、シンクライアント、断続的に接続されたセンサーなどからなる複雑なスタックであり、相互に絡み合っています。その結果、Docke化アプリケーションなどの1つのソースから発せられるアラートは、実際にはインフラの他の部分に根をもつ可能性があります(Dockerホストサーバが接続されているストレージアレイなど)。

いくつかの問題はより深刻

これは、インシデント管理の経験がある人にとっては自明のことです。それでも、今日の問題の範囲がどれくらい広がっているのか、アラートの重大度をすばやく解釈することがどれほど難しいのかを強調しておきましょう。たとえば、ストレージサーバが応答を停止したことを知らせるアラートは、一見すると非常に深刻に思えるかもしれません。ただし、サーバが自動フェイルオーバーを備えたスケールアウトされたストレージクラスタの一部である場合、ダウンタイムは実際には最優先事項ではありません。データが失われる可能性は低く、チームがすぐに問題に対応しなくともビジネス継続性は中断されません。さらに、一部のアラートは警告としては機能しますが、すぐに対処可能ではありません。その情報は、インフラストラクチャ全体のレベルでの異常検出のために保持する必要がありますが、アラートの嵐に疲れてしまわないために、人間の反応のトリガーにならないよう抑止する必要があります。

リアルタイム応答の重要性

今日の常時稼働の世界では、ユーザーはサービスの失敗をリアルタイムで知ることができます。したがって、アラート管理プロセスはリアルタイムでも発生する必要があります。あなたの会社に連絡する前に、SNSのような公開の場所に書き込む傾向があるという事実は、リアルタイム解決をより緊急事項にします。反応的ではなく積極的に行動する、顧客が怒りのツイートをするまでアラート対処を待つことは望ましくありません。

アプリケーションパフォーマンスの問題

アプリケーションが実行されていることを単に確認するだけでは不十分です。ユーザーはパフォーマンスの低下に対してほとんど忍耐力を持たないため、パフォーマンスを最善にする必要があります。たとえば、Webサイトの速度が遅い場合、顧客は10秒待たずに別のサイトに移動します。アラートの観点からこれが意味することは、アプリケーションが完全に応答を停止したときに通知されるだけでは不十分だということです。稼働の監視は重要ですが、パフォーマンスの低下に関するアラートも受け取る必要があります。さらに、無応答アラートと区別できる必要があります。

アラートを微妙に調整

最新のアラート管理の課題は以上のようなものですが、ではどのように解決できるでしょうか。 答えはアラート管理プロセスを非常に柔軟に、より機敏にすることです。次のような戦略を採用します。

優先順位の高いアラートを目立つようにする

最も重大なアラートに迅速に対応するには、それが簡単に見分けられる必要があります。優先度の高いアラートと優先度の低いアラートがダッシュボード上で混在していると、双方を見分けるのは困難です。監視ソフトが優先度の高いアラートをマークすればはるかに簡単になります。

役に立たない警告を抑止する

役に立たないアラートを排除することで、ダッシュボードの視認性を向上させることができます。新しいユーザーアカウントの作成など、優先度の低いイベントのアラートを抑制することなどです。このようなアラートを完全に無効にするのではなく抑止する利点は、緊急の時は紛らわされず、かつ必要に応じて表示させることができるからです。

微妙なアラートの報告と抑制

抑制は必ずしも命題ではありません。特定の状況では特定の種類のアラートをいくつか抑制できますが、他の状況では抑制しないことを選択できます。

たとえば、就業時間内にスタッフがアカウントを作成しているときにはアカウント作成に関連するアラートを抑制し、時間外に行った場合はアラートを表示する、ということができます。または、再起動が一定時間内に3回以上行われない限り、サーバの再起動に関する警告を抑制したい場合もあります。

また、重複した対策やコミュニケーションを防ぐため、関連するアラート間の関連付けを作成することも重要です。

重要なイベントを見逃さずにアラートノイズを最小限に抑えるには、抑止、関連アラートのグループ化、通知閾値のカスタマイズなどを実行し、アラートの重要度をより洗練された方法で判定する必要があります。

アラートによって送信先を変える

すべてのアラートをチームの全員に送るのは非効率的です。異なるタイプのアラートは、各人のスキルとスケジュールに応じて異なるメンバーに送る必要があります。対応する者が異なるということは、アラートの柔軟な割り当てが重要だということです。次の1時間インシデント管理にあたるエキスパートは、その後は非番になるかもしれません。

最初から適切な人にアラートを送信するようにしておくことで、問題を判定してスタッフに割り当てるために必要な手作業の多くを省くことができます。

システムダウンだけではない監視

前述のように、アラート管理の成功は今日、障害だけでなくパフォーマンスの低下を検出することを意味します。このため、システムが容量の限界に近づいたとき(ネットワーク負荷が80%を超える場合や、アプリケーションのCPUタイムが閾値に達したが、まだそれを超えていない場合)にアラートを生成するように監視ソフトウェアを設定することが重要です。

もちろん、これらのアラートに重大な障害と同じ優先順位を付ける必要はありません。障害インシデントは、直ちに知り直ちに処理することがより重要になります。しかし、何かが完全に壊れるまで待ちたいとも思いません。代わりに、アラート処理を最適化して、パフォーマンスの問題がシステムダウンに発展する前に処理できるようにします。

DevOps時代には、インフラストラクチャはアジャイルです。アラート管理プロセスもそうあるべきです。すべてのアラートが同等の重要性を有すると仮定したり、すべてのアラートを報告したりレビューしたりする必要があるとした時代は終わりました。圧倒されることなく現在の複雑で変化の激しいインフラストラクチャを監視するには、アラートに対する最適化されたアプローチが必要です。アラートを重要度に応じて識別し解釈するIT組織の能力が試されます。

続きを読む
インシデント&アラート
2021年8月23日  (更新日:2022年3月8日)

DevOpsのROIを測定する方法

DevOpsは、ソフトウェアの提供とインフラストラクチャの変更のプロセスを自動化および加速しながら、ソフトウェア開発者とIT運用の専門家の間のコラボレーションとコミュニケーションを強調する文化、ムーブメント、実践手法です。 DevOpsプラクティスを実装するには、人、教育、ツール、組織の調整など、いくつかの種類の投資が必要です。しかし、これらの投資から組織が受け取るリターンを判断するのは難しい場合があります。効果測定では何を重視しますか? どうやって投資を価値あるものにしますか?

DevOpsがROIに与える影響

DevOpsのない世界では、ソフトウェアリリースの頻度は低く、以前のリリース以降に開発チームによって構築されたすべての新機能、更新、および変更が含まれています。ビルドされたが次のリリースまで出荷されないコードは、ビジネスには何の価値も生み出しません。コードのユーザーへの配信を加速するということは、ジャストインタイムの製造のようなものであり、完了後すぐに価値を生み出します。そして、今日の継続的なデジタルトランスフォーメーションの世界では、新しい機能をデプロイし、競合他社よりも早く問題を解決する能力が、市場での優位性につながるのです。 DevOpsの主な目標の1つは、ソフトウェアリリースを頻繁に、定期的に、自動化することです。1日に複数回リリースする能力がある場合、個々の本番環境へのプッシュはたいしたことではありません。リリース頻度の低い「ビッグバン」スタイルの体制、つまり全員が臨戦態勢で、土壇場でのトラブルシューティングに追われ、やり遂げるまで深夜も週末も作業する運用チームを必要とするような体制と比較してください。デプロイの失敗によるダウンタイムを解決するために髪を振り乱すのではなく、より幸せで休息の取れた運用チームが次の問題を積極的に解決することの方が、組織にとって明らかにはるかに大きな価値があります。

あなたのチームはあなたの最大の資産です

DevOpsを実装する最良の方法は、解決が必要な問題に権限と責任の両方を集中させることです。最前線のチームは、時間が無駄になっているところ、隠れた非効率性がどこにあるのか、どこに最適化の機会があるのかを知る最適な立場にあります。プロセスに自動化を導入することについての最大の誤解のひとつは、それが必然的にチームから仕事を奪うということです。むしろ、面倒な手作業を自動化に置き換えることで、チームはより価値の高い活動に集中できるようになるのです。 結局のところ、あなたのビジネスをあなたのチームよりよく知っている人たちはいません。人件費にどれだけ投資したかを考えてください。チームの生産性を最大化することは、DevOpsを実装することによるROIの大きな改善点です。重要な問題の解決に時間を費やしてもらうことで、ビジネス全体の成果の量と質が向上し、面倒なエラーが発生しやすいタスクがToDoリストから削除されるため、リスクが排除されます。

ROIをビジネスの目標に結び付ける

では、DevOpsプラクティスを採用するためのビジネスケースを検証するために、ROIの適切な指標をどう選択すればいいでしょうか? これはビジネスにとって大変重要なことです。デジタルトランスフォーメーションが広がるにつれ、新しいビジネスモデルと顧客との新しい対話方法が、あらゆる業界で生み出される価値を根本的に変えています。成功を測定するための鍵は、ユーザーに提供する独自の価値を理解し、それを達成するために指標を結び付けることです。顧客が目標を達成するために費やす時間を最小限に抑える、ユーザーあたりの収益を最大化するなど、DevOpsへの投資を主要なビジネス指標の改善に直接関連付けることができるはずです。

			時は金なり
			鍵は効率化
			柔軟に最適化を
		
	
	
		
			チームがより価値の高い問題に時間を費やすことができれば、あなたのビジネスにより多くの価値をもたらすでしょう。
			ボトルネックを防ぐために、問題に近い現場に権限と責任を持たせましょう。	
			どんなケースでも即通用するというものではありません。ビジネスにとって何が重要かを把握し、そのために最適化を図ってください。

そして忘れてはいけないのは、何かを測定できるからといって、そうする必要があるとは限らないということです。我々は時にビジネスの目標に関係ない指標に気を取られてしまいがちです。開発者の生産性を測定するためには非常に多くのツールが利用可能であるため、記述されたコードの行数や修正されたバグの数など、実際には重要ではないあらゆる種類のデータを追跡できます。計算や最適化は簡単かもしれませんが、ユーザーのために生み出そうとしている価値とは実際には関係のないことです。

「数えれられることすべてが大事なわけではないし、大事なことすべてが数えられるわけではない。」(ウィリアム・ブルース・キャメロン)

ビジネスへの教訓

DevOpsの変革とは、ITの流れを加速することを目的としたプロセスの変更がすべてです。つまり、ROIを測定する際の最大の課題は、DevOpsが提供するさまざまな種類のメリットを理解し、それらのメリットをビジネス目標に結び付けることができるかどうか、ということなのです。 配信されないソフトウェア在庫の山の削減から、手作業による障害リスクの削減、生産性と従業員の満足度の向上まで、DevOpsプラクティスを実装することの価値はすぐに得られます。今日のデジタル環境で競争力を維持しようとしている企業にとって、DevOpsに移行する余裕があるかどうかという問題は、「DevOpsに移行せず現状のままで安泰なのか?」という問いになってきています。

ROIの決定に使用できるDevOps指標

これらをあなたのビジネス目標に当てはめてください

			指標
			詳細とメリット
		
	
	
		
			1日/週/月あたりの本番環境へのプッシュ数
			本番環境への展開の頻度を増やすことで、ユーザーにビジネス価値を提供する速度を上げ、「倉庫の在庫」コードを減らすことができます。
		
		
			1か月/年あたりのダウンタイムの分数	
			自動化が進むと、アプリケーションのダウンタイムが削減されます。これは、ユーザーの満足度と収益に直接関係します
		
		
			自動テストカバレッジ	
			自動化を広範に使用すればするほど、手動エラーの可能性が少なくなり、移動が速くなります。
		
		
			新入社員がコードを本番環境にデプロイするのに必要な時間	
			新入社員が迅速に対応できるようにするためのフレームワークとプロセスを構築することで、新入社員の生産性が向上し、既存のチームの生産性も向上します。
		
		
			新しいイニシアチブと既存のプロセスの実行に費やされた従業員の時間	
			手動プロセスを自動化することで、チームは既存の問題に対処するのではなく、ボールを前進させることに時間を費やすことができます。
		
		
			従業員の幸せ	
			作業に忙殺されるのではなく貴重な問題に時間を費やしている幸せな労働者は、生産性が高く、長期間にわたって戦力となってくれます。これは、NPS(Net Promoter Score)を介して直接測定することも、トラブルシューティングに追われる夜と週末の数を介して間接的に測定することもできます。
続きを読む
DevOps
2020年7月8日  (更新日:2022年3月8日)

インシデント対応から得た分散型コミュニケーションの教訓

新型コロナウイルス(COVID-19)の報告例が世界中で増加し続けていることから、多くの企業では、従業員の感染を最小限に抑える方法として、リモートワークへのシフトが進んでいます。しかし、多くの企業は現在、業務を完全なリモートワークに移行するためにはどうすればよいのか、悩んでいるのが現状です。

企業が急速に分散型組織への移行を考えようとしている中、インシデント対応のパターンを見ることで、数多くの教訓を得ることができます。

リモートワークへの移行

企業がますますリモートワークを採用するようになってきている中で、ITとエンジニアリング職はこの変化の先頭に立ってきました。

20年前は、エンジニアリングチームが物理的に同じ場所にいて、オンプレミスのサーバルームで本番アプリケーションを実行し、プライベートなイントラネットですべての作業を行うのが一般的でした。IT チームとエンジニアリングチームは現場にいて、運用チームがサーバールームにクラッシュカートを走らせるころ、開発チームとマネージャーは、インシデント対応のための作戦室である会議室に集まり始めていました。重大なインシデントが発生した場合、マネージャーがネクステル社の携帯電話を使って、その日外出していたエンジニアに無線で連絡を取り、トラブルシューティングを支援できるようにVPN接続を指示することもありました。

この10年間で、クラウド環境とアプリケーションを使用するようになったことで、世界中のどこからでも本番用アプリケーションにアクセスできるようになりました。今日では、これらのチームが分散して活動することが一般的になっています。その結果、ITとエンジニアリングチームは、リモートで作業する際の効果的な方法を開発する最前線に立っています。

オンサイトサーバ、イントラネット、物理的なインシデント対策室の時代は、多くの組織では一般的に、より近代的なソリューションに取って代わられてきています。これらのソリューションとワークフローがどのように組み合わされているかを検証することは、分散型ワークへのシフトをどのように行うべきか悩んでいる組織に役立つでしょう。

10年間のリアルタイム運用管理の教訓

PagerDutyは10年以上にわたり、何千もの組織がリアルタイムのオペレーションを管理するのを支援してきました。私たちの生活は、デジタルファーストの体験にますます接続されるようになり、世界は常にオンになっていることを意味します。顧客は完璧さを求めており、問題が発生したときの解決までの時間は、数時間ではなく、ほんの数秒しかありません。リアルタイムオペレーションを効果的に管理することは、1秒1秒が重要な時に、適切な人員が適切なタイミングで対応し、コミュニケーションを調整することです。これは、世界中のどこにいようとも、すべてのチームやチームメンバー、部門、リーダーがリアルタイムで起こっているアクションに関与し、情報を得て、連携することを確実にすることを意味します。

PagerDutyは、インシデント対応のリーダーとして広く認識されています。そこで私たちは、リモートチームのための効果的なコミュニケーションを管理する方法について、私たちが教えることができる教訓を見てみることから始めるのが当然のことだと考えました。PagerDutyでは、私たちのチームがどこにいても、リアルタイムの仕事を効果的に管理するために、私たち自身のプラットフォームだけでなく、他のいくつかのリモート生産性ツール(PagerDutyではSlackとZoomを使用しています)を利用して、発生したインシデントに対応しています。

大規模なインシデントが発生した場合、当社の社員はPagerDutyのプラットフォームを使用して、解決に向けて作業を進める際に必要に応じて、様々なチームにまたがって適切なその分野の専門家に連絡を取ることができるようにしています。物理的な作戦室は、ビデオ会議ブリッジ(必要に応じて、バックアップの電話回線があります)と、すべての重要なコミュニケーションをキャプチャする専用のチャットルームの組み合わせに置き換えられました。

リモートで仕事をする際には、いくつかのコミュニケーション方法が鍵となります。

インフォーマルなコミュニケーションチャネルは、フォーマルなコミュニケーションチャネルに置き換えるべきです 口頭での説明に頼るのではなく、知識を書き留めて記録すべきです 必要に応じて情報を制限するのではなく、内部で情報を共有しましょう

インシデントが発生した際には、その場しのぎの通信チャネルを持つのではなく、私たちのチームは、よく知られた明文化された通信チャネルを使用します。インシデントが発生し彼らの参加が要求されたとき、彼らはすでにどの通信チャネルに参加すべきかを知っているはずです。しかし、万が一に備えて、PagerDutyプラットフォームは、ワンクリックでそれらのチャネルに参加するためのリンクが埋め込まれた通知を送信します。

インシデントの管理は、速いペースで行われるストレスの多い仕事です。その作業を調整するために必要なコミュニケーションの多くは、ビデオ会議で口頭で行われます。しかし、知識を確実に書き留めて記録するために、すべてのインシデントコールには、重要な事実と取られたアクションを記録し、対処すべきフォローアップ項目を追跡することで、インシデント中の重要なイベントのタイムラインを作成する記録係が割り当てられています。当社のビデオ会議ソリューションでは、通話の自動テープ起こしを作成することができます。しかし、記録係によって作成されたメモは、発生した出来事を迅速に把握したい場合の参考資料として活用することができます。

記録係は、専用のチャットチャネルでタイムラインを記録します。そうすることで、他の対応者は(対応者として、またはオブザーバーとして)参加したときに、タイムラインを参照して見逃したことをすぐにキャッチアップすることができます。オブザーバーは、状況をよりよく理解したい場合は、専用のチャットチャネルやビデオ通話(聴取専用モード)に参加することをお勧めします。

インシデントが発生している間、当社のチームは通常、社内外の利害関係者に更新情報を送信し、最新のイベントを知らせます。内部の利害関係者には経営幹部、ビジネスオーナー、顧客対応チームなどが含まれ、外部の利害関係者には顧客が含まれます。これらの通知はPagerDutyプラットフォームによって管理されています。しかし、その通知を送信するまでの意思決定は、何を伝えるかの合意を含めて、記録係のタイムラインの一部として記録され、専用のチャットチャネルにも記録されます。

このように口頭でのコミュニケーションと記録されたコミュニケーションのバランスが取れているため、分散したチームが迅速に作業し、より広い組織に効果的にコミュニケーションを取ることができます。記録係のタイムラインを専用のチャットチャネルに記録することで、既存のPagerDutyとのインテグレーション機能を使用して、インシデント後のレビューに自動的に組み込むことができるようになります。

ここでは、インシデントの解決に至るまでの出来事を要約し、原因となった要因を特定し、将来的にこの種のインシデントを軽減するのに役立つであろう 合意された行動項目を文書化しています。これらの事後検証は社内で共有され、物理的な場所に関係なく、どのチームでもイベントをよりよく理解できるようになります。

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

続きを読む
ベストプラクティス