今回はサービスに対して変更を入れる場合は、
お客様との約束(ニギリ)がどうなっているかが重要という話です。

私が担当している業務はリリース展開業務で
開発Tからテスト完了済みのモジュールを受け取り、リリース判定という運用試験の結果と本番環境展開手順の判定会を実施し、
本番環境へ展開する作業を主に担当しています。

今回はその中で展開作業に関して得た気付きを共有します。

※note内ではリリース作業ではなく展開作業という言葉を使います。
　下記参考記事にもありますが、リリースと展開は正確には異なります。

「リリース」とは開発したソフトウェアに対するテストが成功して、製品版（リリース版）を出荷することを指します。この段階ではまだ「展開」はしていません。「展開」とは製品版を本番環境に導入してユーザーが利用できる状態のことをいいます。

▼事前合意はとても重要

展開作業時、担当者はどうしても「自分達の作業手順」ばかりに目が行きがちになります。しかし、それと同じぐらい、むしろそれ以上に確認しておかなければならないのが「お客様との条件合意(ニギリ)」です。

私の現場ではリリース判定前に下記は必ず決めなければなりません。

1. サービスの停止はいつからいつまで？(何分？何回？)
2. 具体的なサービス影響は？
3. データの変更禁止期間はいつからいつまで？
4. 万が一、変更禁止期間に変更してたらデータは破棄される？
5. 問題があった場合の切り戻し判断はいつまで可能？
6. 問題があった場合の連絡は誰がどのタイミングで判断する？

結構多いですね。。
しかし、そのサービスがお客様の業務プロセスの根幹を握っている場合もあるのです。

例えば、最近だと社内の人事手続きにSmartHRなどのクラウドサービスを利用している場合も多いですね。社内業務を効率化できるサービスは非常に有意義ですが、それだけにサービスが停止した場合のダメージはものすごく大きいです。

例えば、顧客が認識していない状況でSmartHRが三日間止まったら、利用している顧客からは怒鳴り声が聞こえてくるのではないでしょうか。
「来月から入社の手続きをしていた人材の入社が遅れた！どうしてくれるんだ！」とか、、

新しいバージョンのアプリケーションをリリースする際も上記のような問題が起きないよう、お客様にサービス停止を事前告知します。
サービスにもよりますが、告知は大体利用停止となる1ヶ月〜2週間前ぐらいには実施されるようです。

この際に連絡する停止時間がお客様との事前合意事項になります。
展開作業時はバージョンアップできることだけでなく、上記の合意をどれだけ守れるかもお客様がサービスを使い続けてくれるための指標になります。

▼顧客影響を意識する

サービス停止の合意について、どんなに停止時間が長い作業手順でも、お客様から合意を得られていればOKだし、逆にサービスの停止が5分でもお客様からの合意がなければNGです。全てはお客様との合意次第となります。

同じアプリケーションだからといって、全く同じ展開作業の仕方をすれば良いとは限りません。

例えば、同じアンケートシステムでも、下記では重要度や緊急度が全く違います。

A: 地域集会の実施日を決める為のアンケート
B: 企業が新型コロナ感染チェックのための毎日の検温結果アンケート

Aならば使う頻度もそこまで高くないですし、
人数もそこまでではないため、別の代替え手段が見つかりやすいですが、Bならば出社する日は毎日利用するため、1日停止するのも嫌がられるでしょう。また、一番利用する朝のタイミングでの利用停止は顧客からのクレームになりかねません。

上記のような背景があるため、
現場の上長からはサービスが停止したときの顧客影響を考えて展開作業を実施するようにと指導されています。

実際、IPAのITサービスマネージャ試験問題でも、
「○○サービスについては、顧客利用の少ない時間帯(昼休みなど)に展開作業を実施する」という回答が準備されておりました。

▼その条件、ちゃんとお客様まで伝わってる？

もう一つ落とし穴として、専用環境などの場合
チームで合意した条件がちゃんとお客様まで伝わっているかにも目を光らせておきたいです。

私は過去次のような場面にでくわしたことがあります。

開発側は不具合なく完璧なプログラムを納品、
運用側の受入試験・展開手順もバッチリ、
しかし、いざ展開作業を実施する当日になって
営業担当がお客様にサービス停止条件を伝え切れていなかったため、展開スケジュールがリスケとなり二週間ずれました。。

はたから見ると、そんなの伝え切れてない営業が悪いという声が聞こえてくるかもしれませんが、お客様から見れば社内の誰がやらかしていようと
サービスの品質が悪いと見られてしまいます。

展開作業は、全ての担当が正しくボールを繋いで完了します。
他人の作業も他人事だと思わず、どこかで問題が起きていないかを常に確認するようにしましょう。運用統制をするのが運用管理者の使命です。

▼それでもトラブルはやってくる

ちなみに、ここまで入念に準備しても展開当日のトラブルはあります。

例) 下記いずれも実話
1. 手順を一つ飛ばしてしまい、WEBサーバが立ち上がらない。
2. 作業中にメンテ用PCがブルースクリーンで作業続行不可。
3. サーバをリブートしたら、そのままサーバ故障。
4. メンテナンス用PCが強制WindowsUpdate開始。

過去データセンターの移設作業を実施したことがあるのですが、そのときには「朝チームメンバー体調不良で集まれなかったらどうするか？」ということまで展開手順に記載されていました。

サービス運用者としては想定外だからといってサービス品質を落とすわけにはいかないので、起こりそうなことは可能な限り考えて対策をしていきますが、なかなかうまくいかないことも多いのが現実ですね。。

まだまだ奥が深い、運用者の道なのでした。

それでは今日はこの辺で。