「システム運用アンチパターン」を読んだ

最近、

ソフトウェアの品質のみを業務の対象と捉えるのはQAエンジニアの活動として不十分ではないか。運用やオペレーションまで含めた組織のプロセス改善を考えなければ、、

という謎の使命感に囚われていたため、オライリーの「システム運用アンチパターン」を読んだ。

www.oreilly.co.jp

結論から言うと、「そうだよね、システムを運用しだすとこういう課題出てくるよね」と身に覚えのあるトピックがうまく言語化されており非常に面白かった。

また、タスクの自動化や可視化、文化の作り方や情報の取り扱い方など、具体的な解決策も挙げられていてウンウンと頷きながら読むことができた。

身近な話だと、QA業務においてもタスクの自動化は重要で、例えばテストデータの作成に毎度毎度複数日費やしていたり、開発環境-テスト環境-本番環境がいつの間にかそれぞれ異なる設定になっていたりすることがある（このような場合、テストの結果を信頼できないため再実行する羽目になる）。僕もこのような課題に対してスクリプトを書いて解決してきた経験があるので他人事とは思えない内容であった。

本書で特に興味深かったのは「大きなインシデントが発生して組織にトラウマが生まれたときどう解決するか」というトピックで、よくある解決策として「承認プロセスを追加する」というアイデアが採用されるが、これはDevOps的には悪手で、何故かというと、特定の人物に業務と責任が偏るし、承認プロセスの追加により生産性の低下やリリース頻度の低下を招いてしまうからというものであった（例えば、タスク自体は60分で完了するはずなのに、特定の承認プロセスを挟むせいで2-3日間手が止まってしまうことがある）。

全体を通すと、マインドセットの持ち方やコミュニケーションの取り方、課題への向き合い方など、心や意志にだいぶページを割いていたのが印象的だった。とてもよい読書体験ができた気がする。