DevOpsの実践法（前半）

ここからは、さまざまな DevOps の 実践法を見ていきましょう。 どれも万能ではなく、 DevOps に必須なわけでもありませんが、 実際に行われているものを 10 種類紹介しますので、 参考にしてください。 一つずつ見て行きましょう。 １番は、 インシデントコマンドシステムです。 IT では、サービスの不具合を インシデントといいます。 従来のインシデント管理体制は、 大規模なインシデントを 想定したものでしたが、現実は ほとんどが小さなインシデントの 寄せ集めです。 ある会議で提唱された 『IT のためのインシデントコマンド』は、 消防署をヒントにしています。 緊急出動の現場で使われている インシデントコマンドの仕組みが IT システムのインシデントにも 大小問わず応用できるというのです。 私も多くの企業に導入し、 効果を実感しました。 不測の事態に対応する 担当者に、余計な手間をかけずに 解決を助ける、稀有な仕組みです。 ２番は、オンコール開発者です。 従来のアプリケーション開発企業は、 「とにかく作れば、 誰かが動かしてくれる」 という方針でしたが、 それではうまくいきませんでした。 開発担当者が相談を 受ける体制を作ったことで、 フィードバックループと 記録、デプロイが向上しました。 応急処置としてサーバーを再起動しつつ、 根本的なアプリケーションの問題も 迅速に解決できるようになりました。 続いて３番は、ステータスページです。 システムの問題は避けられません。 問題が起きても顧客満足を高め、 信頼を維持する 唯一の道がコミュニケーションです。 これは、問題発生時にユーザーが 状況をすぐ把握できる公開の ステータスページを 設置する重要性について呼びかけた、 有名なブログです。 私も、自分が手がけるサービスには 必ずステータスページを作って、 発生した問題、対応の状況、 その後の調査で判明した事実を すべてユーザーに公開しています。 ４番は、非難しない事後分析です。 長年の研究により、 インシデントの根本原因は１つに 絞れないことや、 人的ミスのせいにせず、 包括的に対策する必要があることが 指摘されています。 ジョン・オルスポーは 『非難しない事後分析と 公正な組織文化』という記事で、 望ましい原因究明と改善の方法を考察し、…