夏期休暇のある会社も多いと思いますがそういった休暇期間の前は、大きなシステム変更はできるだけ行わないのが鉄則です。
なぜかと言うと、システム障害の発生率はシステム変更後に高くなるからです。何も変更しない場合は本当に大きな障害は少ない。システム変更と言ったってアプリケーションの変更から、再起動を伴うメンテナンスまでいろいろです。とにかく、大きな休みの前には変更はするな、と。一週間で言えば金曜日は土日の前なので作業はあまり入れません。翌日休みの日に何か起こると対応が遅れるからです。
システム変更を行った際にそれらが全て想定通りに行われたらよいのですが、実は作業内容に勘違いが含まれていて誤作動の原因となったりもします。しかも修正した直後は気づかなくて少し時間が経ってからその間違いが何らかの障害を引き起こします。ところがそのときに休暇がはまっていると、休暇中であれ誰かが修正しないといけないのですが、直接の担当者はつかまらないかもしれません。誰か別の担当者がアサインできたとしても、問題の原因にたどり着くかと言えば、着くかもしれませんが時間がかかります。直近で行った作業も詳しくは知らないので、中身を確認しなければいけません。しかもその作業が別の部門からの依頼だった場合には、その部門の関係者まで連絡し、調整しなければいけないかもしれません。もし顧客向けのシステムだった場合は、顧客に連絡するために営業部門との調整しなければいけません。休み中にリスクを負うのを避けるために、作業はできるだけ凍結します。
昨今は、変更を短期間にできるようにしようと、Kubernetesなどコンテナを使ったCI/CDと呼ばれる開発サイクルの高速化は良く話題に上ります。リリースした後何か問題があったらすぐに戻す（ロールバック）ことでリリース時の問題の戻しも自動化する。一見良いことなのですが、冒頭のシステム変更直後に障害リスク確率が上がることを考えると、あまり真に受けられるものではないのではないかと思う次第です。
CI/CDであっても、リリース期間を短くすることは避け、テストやリリースに対する手間が楽になった部分はもっと品質の向上に時間を使ってほしい、ということです。ソフトウェアはテストに合格すれば必ず正しく動くというのは言い切れません。テストの考慮ミスや、そもそもの仕様変更がユーザーフレンドリーではなく、批判にさらされ戻さなければいけなくなるということもあり得ます。どんどん変更していくというCI/CDのイメージの方が先行していますが、これまでのシステム運用の経験から考えると、たくさんの変更は、想定外の状況を引き起こしやすいです。また、ロールバックしたときに、本当に前の状態に戻るかも１００％とは言い切れません。なぜならシステム変更後にデータ構造を変える場合があり、戻したら戻したで不具合が出る場合もあるからです。
元々アジャイルやCI/CDが指示された理由としては、ウォーターフォールではビジネスのスピードに追随できない。ビジネス環境の激変の速度に追いつけない、というものがありました。
ではアジャイルでは追いつけるのかというと、少し単純化し過ぎて現場を見ていないと思います。リリースのスピードを上げると言っても月に一度程度。そして不具合によるロールバックはおそらくユーザーにはほとんど許されません。例えば何かのスマホゲームでリリース作業がありメンテナンスでプレー中止を十時間行い、何かその後不具合が見つかって緊急メンテナンスに入ったとしたら、ユーザーが不満を覚えますよね。だから、簡単に戻せるからCI/CDがいいというのは短絡的です。リリース作業に対する負荷を減らしたのなら、リリース感覚を短くするのではなく、品質の高いリリースを行うことに空いた時間を使うべきです。
私もいくつかのシステムの運用を預かっていて、たくさんの変更を行うシステムとそうでないシステムの間で、どう見てもシステム障害とは言わないまでも手間が増えることについて、明らかな差があると感じています。ぜひ、変更はリスクを伴うことは、どんなにシステム基盤が変わっても、頭の中に入れておきたいものです。
