【DevOpsアンチパターン①】人を介した承認プロセスの増殖

DevOpsアンチパターンシリーズでは、オライリー出版の「システム運用アンチパターン」の内容を参考に、筆者の経験や意見を交えてまとめていく。
この本で紹介されているアンチパターンは「ありがちだな…」と心を痛めるような運用ばかり紹介されているので、ものすごくオススメ。
アンチパターンベースで話が進んでいくのでDevOpsの必要性を理解しやすい。
詳しい内容が気になったらぜひ本書を手に取ってみてほしい。

承認プロセスの本質を見極めろ！

システム運用をする時に何かにつけて登場してくる承認プロセス、これを読んでいる人はシステム運用に少なからず興味があるはずだから心当たりがあるだろう。
特にシステムに変更を加える時によく出てくる承認プロセスだが、他の部署に実行の了承を得たり、関係各所とタイミングを調整したり、いろんな局面で使われているはずだ。
ツールやサービスを使ってワークフローを回している組織も多いだろう。

承認プロセスを安易に増やすのはよくないと言うのが今回の主旨であるが、承認プロセスは悪だ！と叫んで避けているような組織は少ないのではないだろうか。
私はそのような組織をほとんど見た事がない。
もしあなたの組織がそうであれば、それはおそらくDevOps文化が完全に定着した素晴らしい組織なのだろう。

もちろん承認プロセスってめんどくさいよね…と言うのはほとんど全員の共通認識だと思うが、だからと言って減らしたいから無くすという決断をしている組織はないだろう。
なぜなら無くせる程度の承認プロセスなんて最初から誰も作ろうなんて言い出さないからだ。

本記事でも、承認プロセスを無くそうと言いたいわけではない。
無くすのではなく、人による承認を得るのはやめようと言うのが本記事（というより参考にした書籍）の主張である。

ここまで読んでDevOpsを少し知っている方であれば、あーはいはい、自動化ね。と思っただろう。
実際その通りなのだが、筆者はそう簡単な話ではないと思っている。

具体例を挙げた方がわかりやすいと思うので、まず参考書籍のアンチパターンに出てくる例を簡単に紹介する。

このケースでは、ある会社に運用チームが請求システムに対してデプロイを行なう。
普段であれば請求チームが作業していない時間帯でのデプロイだったが、たまたまその日は請求チームが特別な作業を行なっていたため、請求チームの作業データは全て消えてしまった。
それが発端となり、運用チームのデプロイ作業は事前に請求チームと時間帯の調整と承認を得てから作業を実施することになった。

というケースで、いかにもありそうだ。
そして参考書籍がこのケースをアンチパターンとして指摘している理由は乱暴に言うと、人による承認は必ずしも必要なものではなく、チェックしたい内容は毎回同じなのでチェックを行うロジックをプログラム化してしまえ！ということである。
このケースにおいては、請求チームが作業をしていないという条件を満たせば良いのであれば、簡単な案だとログインユーザの有無を機械的にチェックすれば良い（それで問題があるのかは請求チームに相談して決める必要はある）

このように承認には明確な目的があるケースが多く、まずはそれを慎重に見極めて、本質的には何がしたいのかを整理することが大事である。
そうすることで、人の手を介する運用を減らす事ができる。

人の手を介することによる煩わしさは今さら語るほどでもないが、少しだけ触れておこう。
自動ではなく、手動の弱点といえばだいたい以下の3つに収まるだろう。

• 時間がかかる

• 手間がかかる

• 品質がまばらになる

そして手動運用は減らせるのであれば減らしたい、というのが共通認識ではあるだろう。
だがなぜかほとんどの組織では自動化はされない。

それはなぜか。一言で言うと組織の「文化」に尽きるだろう。
文化は習慣をうみ、習慣は発想に直結する。
自動化は正義、手動は悪だという価値観を醸成し、共有し、育成し続ける事が何よりも鍵となると思う。