DevOps導入前のメトリックの課題

TL; DR、開発、特に展開の自動化が変更の失敗率を改善することをどのように証明しますか？

私たちは皆、現在の（主に手動の）手段を使用して、「デプロイメントの失敗」に関するメトリックをキャプチャしようとしています。残念ながら、「失敗」はめったに起こりませんよね？何かがうまくいかないとき、チームは一緒に（通常は英雄的に）問題を修正します（通常はアクセス許可、構成の欠落、ドリルを知っています）。だから...展開がどのように進んだかを尋ねると、答えは「うまくいった」です。

しかし、直感的には、それは良くないことです。2017年の開発状況レポートによると、約31〜45％の「変更失敗率」があります。それは直感的には正しいように聞こえますが、インシデントとして追跡されていますか？いや。通常は検証中にかなり迅速に修正されるためです。実際にデプロイメントをロールバックすることは、はるかにまれです。

したがって、故障率を正確に報告するには規律が必要です。私たちは物事が機能することを望んでおり、それを実現するために必要なことをしているので、そのように報告することに無関心です。

では、開発、特に展開の自動化が変更失敗率を改善することをどのように証明しますか？

（PSはこれに「＃devops-capability-model」のタグを付けようとしました）

過去に同様の状況で使用した手法は、すべてのチームメンバーにこれらのルールを課す「管理のコミットメント」を取得することです。

1. 対象の展開領域（つまり、運用）への更新を実行するためのアクセスは、選択した自動化システムに制限されます。自動化されたシステムには、管理する領域に対するあらゆる種類の更新の適切な監査証跡（=ロギング）があります。

2. 何らかの理由で、対象の展開領域を手動で更新することは、以前はこれらの更新を実行（承認）することができた（承認された）一般的なチームメンバー（ユーザーID）によって許可されなくなりました。代わりに、新しい（追加の）ユーザーIDが作成されます。このユーザーIDには、必要なときにいつでも、このような手動更新を（まだ）実行するために必要なすべての権限があります。しかし、実際にそれらの新しいユーザーIDを使用できるようにする（=それらでログオンを実行する）ために、そのような新しいユーザーIDでログオンを実行したいチームメンバーは、パスワードにアクセスするための「いくつかの」追加の手順を実行する必要があります。そのような新しいユーザーID。理想的には、この追加の手順も自動化されています（自分の想像力を使用して、どのように見えるか）。他に何かが失敗した場合は、必要なパスワードのゲートキーパーに連絡してください（=電子メール、電話など）。修正する」

3. そのようなゲートキーパーを設置することは簡単な仕事ではありません。そして、最も抵抗があるのは...チームメンバー（さまざまな理由から）です。そのため、これらの新しいユーザーIDのバリエーション（前のステップと同様）は、各チームメンバーが（ユーザーが自分で決めたパスワードで）追加の​​ユーザーIDを取得しますが、追加の文字列が添付されています。実行できるのは、実際に正当な理由がある場合は、その（追加の）ユーザーIDでログオンします。そして、そのようなログオンを実行するたびに、「修正した問題」についてのある種のレポートを提出する必要があります（質問と同様）。

これらの手順を実施したら、あとは、これらの各レポート/そのような特別なユーザーIDを使用する必要がある理由を定期的に確認し、「これをさらに自動化するためにできることはありますか？そのような特別なログインの必要性をさらに減らしますか？」

更新：

この回答の下の追加コメントからの引用：

展開の問題を修正するために人為的な障壁を追加することは逆効果です。

確かにそれは余分な障壁を追加しますが、私はそれが「人工」であると有罪とは言いません。これは、私の知る限り、次のような理由により、そうでなければチームメンバーが通知しないことを知る唯一の方法だからです。

• 雇用保障。
• 彼らが隠しておくことを好む悪い事/練習。
• 彼らが失いたくない力。

2017年の開発状況レポートによると、「変更失敗率」は約31〜45％です。それは直感的には正しいように聞こえますが、インシデントとして追跡されていますか？いや。通常は検証中にかなり迅速に修正されるためです。

すぐに修正される問題はまだ問題です。これらを報告していない場合、それは問題です。

したがって、故障率を正確に報告するには規律が必要です。私たちは物事が機能することを望んでおり、それを実現するために必要なことをしているので、そのように報告することに無関心です。

実際に物事を機能させることを目標とする場合は、将来失敗を防ぐために、失敗に対して正直である必要があります。彼らの目標は物事が機能しているように見えるようにすることなので、ここのチームは失敗について嘘をついているようです（おそらく彼ら自身、確かに管理者に対して）。

これらは異なるものです。たとえば、QAがバグを生成するという古いジョークを取り上げます-「QAがそれを把握するまで私のコードは問題がなかったので、これらすべてのバグを作成しました！」。バグはずっとありましたが、開発者はそれらに無知でした。運用チームの目標は、実際の信頼性である必要があり、管理者はそのようにインセンティブを与える必要があります。つまり、新しい問題の発見につながるより多くの監視を導入した場合、その後の信頼性指標の低下にペナルティを科せずに、報酬を受け取る必要があります。

TL; DR、開発、特に展開の自動化が変更の失敗率を改善することをどのように証明しますか？

組織の変化を動機づけようとしている場合は、何かを証明しようとするのではなく、他の組織が独自の移行について述べていることの証拠を提供する必要があります。すでに実施しているプロセスを測定し、それらの継続的な存在を正当化しようとしている場合は、平均修復時間（MTTR）などの標準の信頼性メトリックを追跡する必要があります。

しかし、devopsの原則は、信頼性を高めることだけではありません。サイトの信頼性エンジニアリングでも、信頼性を高めるだけではありません。むしろ、適切なレベルの信頼性を獲得したいと考えています。これは、ビジネスにはメリットがありますが、開発の妨げにはなりません。そして、それは変化に力を与えることである本当の動機を開発にもたらします。信頼性の許容範囲内にとどまりながら、ビジネスが市場の刺激に迅速に対応できるようにしたいと考えています。これは、信頼性を測定する必要があることを意味しますが、速度を測定する必要もあります。これは、前者を比較的静的に保ちながら、後者を増やすことを目的としているためです。