はじめに
業務委託の丹羽です。
レバテックフリーランス経由で、レバテック開発部のSREチームに業務委託で参画させていただいています。
業務委託の私でも、我が物顔でレバテック開発部のテックブログに寄稿して構わないとのことなので、今回は掲題の件について、振り返りながら記事にさせていただきます。
ざっくりこんな人
AWSの基盤となるクラウド部分と、EC2内部でOS・ミドルウェアをメインに、各パラメータを修正したり、それらをAnsibleに書き起こしてCodeCommitで管理しているくらいのIaC経験があるインフラの人でした。
そこからスキルアップと挑戦をしたいという思いで、フリーランスに転向してSREやDevOpsに興味を持ち始めた人です。
SLI/SLO...？ CICD...？ 何それ、美味しそう！
話したいこと
フリーランスってどんな仕事してるの？
レバテックフリーランスに興味のある方は、フリーランスとして実際にどのような業務が出来るのか、考えることはありませんか？
案件詳細などからも読み取りづらい部分ではあるので、私は少し不安がありました。
レバテックフリーランス経由で働くエンジニアが、実際どんな業務をしているのかというサンプルとして、赤裸々に公開されているものが少ないと思っていました。
なので、その一つの例として読んでいただけると嬉しく思います。
要するに
リリースに有識者の参加を強制させるため、CD実行時に承認フローを設置しました。
結果的には、警戒していたアンチパターンを見事に踏み抜いて形骸化してしまい、その同じ轍を踏まないための方法として、コミュニケーションが必要だということを改めて感じました。
なぜ承認フローを設けたのか
前提
-
Githubで管理されているリポジトリの承認フローは、mainブランチに対してPRを作成した段階で発生します。ApproveされたPRはmainブランチにmergeすることができ、以降に承認プロセスは発生しません。
-
レバテックのGithub Organizationでは、サービスやチーム毎にメインで管理するリポジトリが異なり、それに関連するパイプラインの管理についても異なります。リリース単位もまばらであり、チームによってはマージからリリースまでのリードタイムが発生し、複数のPRが含まれるリリースとなるケースがあります。
-
リリースは、担当者が一様にPRの内容を認識していることばかりではないため、有識者をチェッカーとして設置した上で作業を行うことが望ましいです。
これらのことを含むあらゆる事情から、リポジトリに対する責任が小さい開発者（私のような業務委託など）に対して、本番環境にアクセスする権限が一部制限されています。
前提に含まれる危険性
上記の前提には、以下の危険性があることを示唆しています。
- 責任のある開発者（チェッカー）を設置せず、いつでも単独でリリースが可能な状態
- 内容を把握していないPRを複数含むリリースとなり、影響範囲に気付けない可能性がある
- リリース担当者によっては、変更された本番環境の状態を参照できないケースがある
これらの危険性は重複して発生する可能性もあり、インシデントの検知を鈍化させ、いずれクリティカルなアクシデントを顕在化させる要因の一つとして、問題視されていました。
解決策として承認フローを設けた
この課題を解決する手段はいくつかありますが、リリースによるインシデントを抑止する措置を取る必要があるということは自明でした。そのため、リリース（CD実行時）に承認フローを発生させ、責任のある開発者のリリースへの参加を強制させる必要がありました。
承認フローの実装について
承認フローを調査する
承認フロー実装のタスクに着手して、まず感じたのは「自由度が高い」という点です。
今まで私が経験していたインフラ関連(主にエラーを解消するなどといった)業務と異なり、解決に至るプロセスが豊富にあると感じました。
そのため、承認フローとして設置できそうな機能を調べ、それぞれのメリット/デメリットを理解するところから始めました。
Github Acrions Environment
例えば、Github Enterpriseで利用できるEnvironment機能です。
- メリット
- 環境ごとに異なるSecrets/Variablesを定義できる。
- BuildやDeployの処理は共通化しつつ、環境ごとに異なる値をGitHub Actionsに渡すことが可能。
- デメリット
- Github Enterpriseのプランに加入している必要がある。
- 承認プロセスの設置というより、パイプラインの改修となるため比較的導入コストが高い。
CodePipeline
他にも、CodePipelineを使用する方法などがあります。
- メリット
- AWSのマネージドサービスを掛け合わせて使用できる。
- デプロイ後のロールバックが容易になる。
- デメリット
- 無料枠を超過した場合、追加で課金する必要がある。
- 構成要素(SNSによる通知設定、承認権限のロール管理、IaCなど)が多くなるため、比較的導入コストが高い。
採用した承認フロー
実際に採用したフローは、任意のCDを実行した際に、指定したSlackチャンネルに承認フローを発生させるというシンプルなものでした。Slack上に出現する「Approve/Reject」のボタンを押下することで、後続処理の続行・停止を行え、設定したタイムアウトの時間になると処理は停止するというものです。
Slackの通知画面
組織のフェーズにより、あるいはチューニングを行うことによって、効果を最大限発揮してくれる優れた機能だと思っています。また実装も比較的容易であることから、スピーディにこの課題を解決したい場合には、最も適した選択の一つだと感じています。
採用した理由
Slackは普段から頻繁に利用するツールであり、仮に承認フローをGithubやCodePipelineで実装したとして、通知先として使用するのも恐らくSlackになります。また、承認権限を与えるユーザはSlackチャンネルに参加させるだけよく、そのチャンネルの参加者であれば、レビュアーとして設定されていない開発者にも通知させることができるため、相互にリリースの状況を把握することができると考えました。
採用する際、最低限必要だと考えたのは以下の四点です。
- 責任のある開発者をリリースに参加させる強制力があること
- 導入コストが低く、スケールさせるのが容易であること
- 開発者の認知負荷が高くないこと
- リリースの障壁とならないこと
しかし、承認フローは機能しなかった。
実際に運用を開始した承認フローは、安全装置としての役割以外に問題を抱えていることが次第に明らかになり、
形骸化していくことになりました。
原因と問題
原因1:組織の理解度
各チームのリポジトリの運用状況、リリースをメインに担当する開発者像の把握ができていませんでした。
前提で述べたようなケースは頻発していないものの、多少あるかも知れないという認識で機能を設計しました。
その影響により、実装したフローは、承認プロセスを必要としない開発者に対してもアクションを要求する形で実装されていました。
問題1:アクションを求める範囲
問題だったと感じているのは、目的外の開発者にもアクションを要求していたことです。
- 責任のある開発者（チェッカー）を設置せず、いつでも単独でリリースが可能な状態
- 内容を把握していないPRを複数含むリリースとなり、影響範囲に気付けない可能性がある
- リリース担当者によっては、変更された本番環境の状態を参照できないケースがある
上記に対する措置として設置する承認フローでしたが、それに当てはまらない開発者に対しても、必ず承認フローが発生し、アクションを要求する実装になっています。
さらに、承認プロセスがリリースの障壁となることを避けるため、リポジトリをメインで扱う責任のある開発者は自身のリリースに対して、承認プロセスを自身でApproveすることができる設計になっていました。
これらの目的に沿わない実装部分が 「ボタンを押すだけの人たち」 を生み出してしまい、形骸化に繋がったと考えられます。
原因2：必要性を感じない
多くの開発者からは、抱えている危険性と中長期的にあるべき姿については概ね同意いただけるものの、直近の所感として「必要性を感じない」というフィードバックが多かったです。
理由として挙げられたのは、現在のリリース状況、リポジトリの運用方法により、前提で述べた危険性はない、もしくは抑止できているという理由でした。
実際に、正社員のみがメインで扱うリポジトリに対して、この承認プロセスが貢献できることは少なかったかも知れません。
問題2：説明不足
またフィードバックの中には「なぜこの形式で承認フローが実装されたのか、また目的は何か」という疑問もありました。この疑問に対する回答として、社内で使用しているDocBaseに開発者向けの資料を作成していましたが、行き届いていませんでした。
資料には以下の内容が含まれています。
- 導入の経緯
- 意思決定に至るまでの経緯と選定理由などを含めた設計へのリンク
- 導入の手引き
- 実装方法と各種設定値に対する説明
- 運用の手引き
- 各種ボタンや機能など、使用方法と注意点の説明
- 質問コーナー
- 何か困り事があれば自由に質問して欲しい旨を記載
こうすれば良かった
承認プロセスは必要なところにだけ置く
当たり前なことを言っているようですが、それについてもっと深く考察するべきでした。
「自分でApprove押せるし、邪魔にはならないだろう」という甘い考えが、結果的に形骸化の呼び水となってしまいました。
「承認プロセスを必要なところだけに置く」という考えを含めると、CDに組み込む形になるこのSlackの承認フローを採用すべきか、というところから考え直す必要がありそうです。
例えば、ユーザ単位で承認プロセスの発生を制御できるような機能を探し、検討することから始めてもいいかも知れません。
あるいは、CDを分けたりブランチ戦略を考え直すことによって、この実装のまま解決する手段もあるかも知れません。
いずれにせよ、グループないしユーザ単位での制御を考え、承認フローを設計する必要がありました。
伝わるのか？を考える
導入の検討から実装に至るまで資料として書き起こしましたが、伝わっていない部分もありました。
これもよくある問題の一つで、ドキュメントは伝わらなければ意味がないという典型でした。
用意した全てのドキュメントに目を通すと相当なボリュームがあるため、開発者向けには別の簡易資料を用意していました。その中では触れらていない部分についての疑問が寄せられている傾向にあり、伝えるべき部分が欠落したドキュメントを渡していた可能性があります。
また、ドキュメントを用意するだけでなく、事前に開発者と打ち合わせを行ってゴールの認識を合わせることで、このような事態を避けられたかも知れません。
事前に「この機能により何を得たいか、そのために誰が何をするのか」を明確に伝えることができていれば、承認プロセスの設置の仕方についても、チームからフィードバックがあって事前に解消されていたかも知れません。
それでも良かったこと
取り外しが簡単であること
該当のPRをRevertするだけで、この承認フローは簡単に取り外すことができます。
「我ながら後ろ向きな良かったところだな」とは思いますが、これを軽視してはならない要素のはずです。
機能を提供するという経験
また、機能を提供してフィードバックを得ることにより、もっとこうしたい！こうすれば良かった！というポイントが出てきました。机上で考えても追いつかない領域や、つい考慮が漏れてしまうことはあると思います。
今まで「新しい機能を使ってもらってフィードバックを得る」という経験がなかったため、今回のタスクでそれらを実感することができたのは、個人的に有意なことだったと思います。
とりわけ リリースするって大事だよな としみじみ感じています。
学んだこと
警戒していても陥るのがアンチパターン
改善点として挙げた以下の二つについて、全く意識していなかったわけではありませんでした。
- 承認プロセスは必要なところにだけ置く
- リリースの障壁にはならないだろう...
- 伝わるか？を考える
- ドキュメントは用意したし大丈夫だろう...
しかし、結果的には上記の二つは完全に運用・ワークフローのアンチパターンとして当て嵌まる形で失敗しました。
ではどうすれば、これらのアンチパターンを回避できたでしょうか。
コミュニケーションは最強
今回のケースの場合、端的に言えば、より前の段階で一度フィードバックをもらうことによって、このアンチパターンを回避できた可能性があります。
ゴールの認識を合わせ、フローの設計や必要となる情報の管理についても解消できたかも知れません。
今回の記事では触れることのできなかった、新たな知見も数多く眠っていると思います。
それらを掘り起こす可能性を秘めているほぼ唯一の手段が、コミュニケーションなのだと実感しました。
そう、コミュニケーションは最強
しかし、人に協力してもらう以外にも改善する方法はあります。
アンチパターンについて学ぶ
アンチパターンについて学ぶことも、自分の中の視点を増やすという意味では有効な手段だと思います。
今回の件をDevOpsと紐付けながら、総合的に理解を深めていくなら以下の書籍が役立ちそうでした。
（早速、購入しました！）
重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。
ネクストアクション
開発者とユーザの近くへ
SREチームに所属して半年が経過しようとしています。まだまだ技術的に追いつけていない面もありますが、日々の作業が誰かの何かしらの体験を良くするかも知れないという感触を一連の業務で得ることができました。
レバテックのSREでは、NewRelicを活用したObservabilityの導入計画が進行中です。
以前にも増して、開発者とユーザの近くでリアクションを受けることができるようになっていきます。
それらの計画に少しでも貢献していけるよう、これからの業務も励んでいきたいと思います。
終わりに
感想
正直最初はこの機能は本当に必要なのか？と自分自身、疑問がありました。それは、運用でカバーすることが最もシンプルで早く課題を解決することができると感じていたからです。
この機能で提供される価値について、徹底的に上長に相談し、資料を作成しては読ませ、打ち合わせを何度か設置して、納得した上で実装方法の検討からリリースまで任せていただいたことは、フリーランスとして参画して間もない私にとっては有意義な時間でした。
初めてのテックブログ
実際に振り返り記事を書くと、このタイトル一つに様々な学びがあることを思い知らされます。
ワークフローのアンチパターンについて学ぶもよし、安全性とは何かを掘り下げることもよし。読んでいただいた方に提供できるものは少ないかも知れませんが、今後も続けていきたいと思いますので、どうぞよろしくお願いいたします。
ありがとうございました。
Discussion