@koic です。
運用上の作業を開発者が行うというのは、昨今の DevOps ではよく見る光景だと思います。そして、運用手順の実施などにおいてダブルチェックというものを聞いたことあるでしょう。いや、むしろプロジェクトのルールで必要とされ、聞いたことがあるというレベルではないケースもあると思います。
そんなダブルチェック文化について、個人的には「ダブルチェックと聞いたらまず必要性を疑って判断する」という立ち位置で、本稿はそういった音楽性の人が書いた記事となります。
なお、一口に「ダブルチェック」といっても定義は広いため、「リアルタイムでの2人以上の指差し確認」を本稿でのダブルチェックの定義として位置付けます。
そもそも人間は間違えうるもの
やるやらないの判断の前段に、ダブルチェックの際には懐疑的に接するという姿勢をしています。理由としては本来的に人間は間違えうるものなので、一人で起きていたミスが二人なら起きないかというと、別にミスが起きなくなるわけではなく、ミスが起きる可能性が減るということが期待になります。
では二人ではなく三人にしたらもっと減る？四人なら？となりますが、一定人数以上になるとミスの検出率は下がるといわれています。随分前でうろ覚えですが、たしか『ピアレビュー』あたりに記述があった気がします。
本稿で扱う「ダブルチェック」の本質はリアルタイムレビューです。ドライバーのセルフレビューは依然として必要ですし、作業者のいずれもダブルチェックが思考停止フラグにならないよう「この相手なら間違えても気付いてもらえるだろう」と気を抜かない方が良いでしょう。というのは理想論で、まあ人間なので気を抜いてしまって見落とす時もあります (実際、私自身が過去何度も見落としたことがある) 。
なので、リスク低減を目指すものの、そもそも間違えうる人間の瞬発性を前提とした作業が「ダブルチェック」というものになりそうです。難しいところです。
本番環境へのショートサーキット 👿
必要にせまられて、本番環境ログインでの直接コマンド操作をするような作業が必要になることがあるでしょう。そんなとき、手順へのレビューがあまりされていないような本番手法は極力控えましょう。データベース操作を伴うような作業で、「rails console を本番環境で直接叩く」といったケースはこのアンチパターンの一例です。
こういった作業を迫られた際の「不安」を感じる際は「ダブルチェック」はひとつの心理的安全性と、ワークアラウンドのリスク低減を得られる手法になりえます。
人間は感情の生き物でもあるので「心が折れそう」とか「不安がある」ときは、普段からのペアワークのこころで声をかけてみると良いでしょう。
https://www.slideshare.net/koic/attitude-of-mind/47
Ops でも Dev のレビューフローにする 👼
本番環境へのショートサーキットに対する正攻法としては、一時運用の作業手順をスクリプト化して GitHub で Pull Request レビューを通すことはひとつのアプローチになります。これは手順の確認や、ミドルウェアへのパフォーマンス影響などの観点レビューを事前に行うことになります。イレギュラーではない、いつもの開発ワークフローですね。
異なる観点によって問題検出率はあがります。緊急の対応だとしても、なるべく普段の開発フローに載せる形で進められれば、イレギュラーなアプローチによるリスクを低減することができるでしょう。
本番環境に入っているときの「ヒリヒリ」した精神下ではなく、非同期で落ち着いたタイミングでレビューできるというようになるので、精神面としてもできるときはこちらを選びたいものです。
仮に本番環境での作業がダブルチェックになったとしても、実行コマンド自体はレビュー済み、場合によってはテスト済みのスクリプト一発で行えるようになります。テスト済みのスクリプト一発実行だけであれば、ダブルチェックは不要になることもあるでしょう。
形骸化したただの着席プロセスになっていないか疑う
見てきた「ダブルチェック」で厳しさを感じるのは「単にルールだから」と十把一絡げに行うものです。
ダブルチェックはそれによって問題を見つけるためのものです。単なる「ルールで横に着席しました」になっていそうなときは、その意図やリスクを元に自動化やフローの改善ができないか疑ってかかってみると、本質的ではないダブルチェックへの手法を改善したり取り除くきっかけにできるかもしれません。
またミスが起きたときに、一人で作業していたものだと責められそうで、二人で作業していたらそこまで責められなさそうというのも不思議なもので、そもそも一人でもミスが起きづらいような仕組みを作る、人間ではなくシステムで行うようにするのが本質的な問題解決になるでしょう。いますぐはできなくても「いつかこの作業を自動化してやるんだ」の気持ちで、初手として未来を良くしていくためのイシューに起こしてみるのも改善への踏み出し方のひとつです。
「ダブルチェックを低減する技術」を紹介しました。ダブルチェックでどんなリスクを低減したいのかということをふりかえるキッカケになれば幸いです。続きはそれぞれの現場にて。
また永和システムマネジメント アジャイル事業部では、マンパワーでの問題解決をエンジニアリングでの解決に転換して進んでいきたいメンバーを募集しています。
