今回はサービスの可視化について書いてみます。
ただし、システムのツールによる可視化ではなく、メンバーの作業に関する可視化です。
ツールは全ての事がわかってから使えばよく、最初からツール化を考えると間違った方向に進んだ場合修正が難しくなります。
面倒でも最初はコミュニケーションも兼ねて手作業で物事を進めましょう。
DevOpsにおける基本を無視する##
最初から不穏なことを言っていますが、DevOpsにおいて
- 障害等の犯人捜しはしない
- なぜ起こったのかを詳しく検証し、次回以降修正する
と言うのがあります。
しかし、縦割りの業務形態では皆が責任を回避しようとし、詳しく調査をおこなわないため、また似たような問題を発生させます。
縦割りの業務形態では責任範囲がはっきりしているわけですから、犯人(責任の所在)探しは重要です。
しかし、ただ単に~が悪いでは、全く意味がありません。
当然のことながら問題が何故発生したのか、いつ発生したのか、どのような状況で発生したのか等詳細に原因追及を行う必要があります(別の部署に責任を被せようとする人もいますから)
DepOpsでは、割と性善説に則っており、問題はみんなで解決しよう、経験はみんなで分かち合い業務を向上させていこうと言う形ですが、縦割り業務には通用しません。
このためにもサービスの可視化は非常に重要な項目となります。
メンバーの作業量、作業内容の可視化###
縦割り業務の最大の問題は、「隣の部署で何をしているかわからない」という事です。
この問題を解決するため各メンバーの
- 1日の作業時間
- 作業内容の比率
を出す必要があります。
非常に面倒な作業ですが、自動化し、手作業が減る事で報告する内容も回数も減るわけですから義務とします。
作業時間が多く、トラブル対応ばかりならそのメンバーの作業に何か問題があることがわかります。
また、作業時間は少ないのにトラブルの原因となることが多い場合は、何か対策が抜けているという事になります。
このようにして全メンバーの作業を可視化することで、トラブル発生時の作業内容や作業時間も把握しやすくなり、原因の特定の容易さにもつながります。
一番大きいのは、「この部署こんなに大変なのか」と言った実態を他の部署が気付けることでしょう。
トラブル発生時の作業手順の可視化###
何か障害が発生した場合、1分でも1秒でも早く復旧したくてむやみに手を動かしてしまう場合があります。
これで素早く復旧することもありますが、当然原因の解析や今後の改善には役に立たないので、多少時間がかかっても、各メンバーが行う作業手順を可視化する必要があります。
ここではプロジェクトマネージャーの手腕が大きくかかわってきますが、各メンバーから提出された作業手順を確認し、どの順序で原因究明をするのか、対策を行うのかを決めなければいけません。
これも最初は非常に大変ですが、サービス運用やトラブル対応が改善されるにつれて、定収される作業手順も正確になり、少なくなっていきます。
対応手順では
- 目的
- 作業時間
- 作業手順
- 想定される結果
を記述します。
目的と想定される結果は重要で、これがないと他のメンバーには作業内容が何のために行われるのか不明になってしまいます。
これらはアジャイル開発のタスクシートと同様にホワイトボードに貼り付けて管理すると便利でしょう。
また、よくある事ですが、対応を行った際新たに問題を発生させてしまった、作業に間違いがある事に気づいたという場合もあります。
既に他のメンバーも対応作業を始めてしまっている場合もあるので、この際にも新しく対応手順を作成し、プロジェクトマネージャーの指示を仰ぐ必要があります。
これもアジャイル開発で作業タスクに誤りを見つけた場合にその場で直すのではなく、アーキテクトに報告するのと同じ手法になります。
この方法の問題はサービス初期には非常に時間がかかる事です。
そのためにも、サービスリリース前に想定されるトラブルシナリオなどを作成し、あらかじめ対応シートを作成しテストしておくことで、リリース初期の対応の遅れをある程度カバーできると思います。
まとめ##
今回は非常に手作業の多い内容となりましたが、最初は手作業でやりましょう。
最初からツールを導入するのは全くお勧めできません。
これはメンバー間のコミュニケーションにも関わってきますので、時代に逆行するようですが、紙とホワイトボードで作業を進めていくことが、その後の効率化にも生きてきます。