私の文章ではDevOpsに関する専門用語はなるべく書かないようにしています。
理由はツールと同じで専門用語を使った事で出来ている気分になってしまうからです。
これからもなるべく平易な文章で書いていきますので、Qiitaの読者層には合わないかもしれませんがご理解ください。
サービスシナリオって何？
サービスの提供は、企画・設計、開発、テスト、リリース、運用、トラブル対応、と言った各フェースが繰り返し行われて成り立っています。
これらを全部一つのチームで行えれば理想的ですが、現実は縦割りの業務に阻まれてしまいます。
古い話ですが2000年ぐらいのころは、「自分で作ったシステムは自分で責任を持つ」と言うのが基本であったため、上記全てを1つのプロジェクトチームが行っていて、かつメンバー全員がそのシステムにプライドを持っていたため、DevOpsなんて言う概念がなくても成り立っていました。
しかし、現在と比べると非常に小さなシステムであって、背後に大型計算機と言った大量の人員と金が使われている大規模システムが存在する上での話でした。
主に各チームが協力し合わなければならないのは、
- テスト
- リリース
- トラブル対応
です。
先日の記事でもトラブル対応のシナリオの話が出ましたが、他チームとの連携が必要な場合は、自分たちの行う作業を周知しなければならないので、作業シナリオを書くと言う作業が必要です。
これらの作業シナリオをここではサービスシナリオと言っています。
初期リリース前に準備しておくもの
企画・設計、開発(単体テストや結合テストを含む)が終わった後、いよいよ運用を前提とした業務テストとリリースが行われます。
この業務テストではインフラから上位アプリケーションまで、関わった人、これから関わる人全てに影響するため、入念に準備をしなければいけません。
具体的には
- 事前確認内容
- 初期データ投入内容確認
- リリース作業
- 初期データ投入
- リリース後状態確認
- サービス正常系確認テスト
- サービス異常系確認テスト
- 負荷テスト
- 業務テスト
- 初期トラブル対応
- 切り戻し(作業中止)確認
- 初期データ再投入
- 稼働確認
と言った作業が行われるため、これら全ての作業をシナリオとして作成しておく必要があります。
とんでもなく面倒な作業ですが、ここで手を抜くとサービスリリース直後からトラブル対応で手が回らなくなり、やっつけ仕事での対応が増え、その後のフェーズに悪影響を残してしまう事になります。
また、ここでシナリオを作っておくと、障害発生時や次回のリリースが格段に楽になりますので、一番やりたくない作業ですが、時間と人員を割いて実行しましょう。
厄介な切り戻し(作業中止)
上記の作業の中で事前準備が難しく、作業当日の判断も難しいのが切り戻し(作業中止)でしょう。
当然、予定していたリリースは遅れてしまいますし、各メンバーの再スケジュールも必要になります。
プロジェクトマネージャーの評価にも影響してきますし、判断を誤る可能性が高い内容です。
しかし、あらかじめ決めた条件やシナリオ通りに作業中止ができる、問題発生の可能性も含めてスケジュールを決められるのが優秀なマネージャーです。
上から言われた日に何とかリリースしないとと頑張って、無理矢理進めてしまう人は上司の評価は良いでしょうけど、その後全てのフェーズの担当者から恨まれることになります。
これが更に業務の分断とコミュニケーション不足を加速させることになります。
こう言う時はマネージャーだけに責任を押し付けないように、各チームもシナリオ通りに進まなかった場合ははっきりと中止を伝えて負担を減らしてあげることが、今後のDevOpsの各フェーズを上手く進めていける
要因となります。
まとめ
簡単に初期リリースの話をまとめました。
初期リリースは作業量が多く大変ですが、サービス開始前ですのでまだまだ楽な方です。
今後はサービス中のシステム変更などが控えています。
いかにサービスを止めずに各チームが連携して作業を進められるのか、初期リリース時よりさらに難しい切り戻し判断ができるのか等、問題は山積みです。