こんにちは。 マネーフォワードのgotoken(@kennygt51)です。
インフラの基盤更改や新規サービスのリリースなど、普段の機能リリースとは違った規模の大きい作業がおこなわれる際には、その作業の全体像やスケジュールを整理するために、リリース計画を立てることがあります。 リリース計画が必要とされる規模の作業は、これまで数多くのITサービスでおこなわれてきたはずです。しかし、リリースを成功させるためのリリース計画を立てるノウハウが体系的にまとまった資料は数少なく、計画を策定する担当者の経験に依存しがちです。
この記事では、大規模なリリース計画を立てる上で重要だと感じた守るべき心がけを列挙するものです。もちろんリリースの規模や特性によって「絶対に守ったほうがいいこと」「そこまでやらなくてもいいこと」があると思いますので、すべてを鵜呑みにすることなく、適宜読み替えてください。 新規サービスのリリースなど、関係者が多岐に渡る大きなリリースを控えるエンジニアに、是非一読頂きたいです。
リリース計画とは「切り戻し計画」である
これだけは絶対に意識して欲しい点なので、一番最初に挙げることにしました。ここまで読んでくれたのなら、この記事の目的は9割達成されたといっても過言ではありません。
リリース計画の中で一番大切なのは何か問題が発生した時の切り戻しの計画です。「切り戻し」とは、リリース作業中に問題が発生した時にリリース作業を中止し、リリース作業を始める前の状態にシステムを ロールバックすることを指します。
ぶっちゃけると、0から10までうまくいくリリース作業なんてほとんどありません。事前の考慮不足・テスト不足でリリースしたけどサービスがうまく動かない、、というのは当たり前に起こることです。 問題が発生した時に「やべぇどうしよう。。」とリリース作業をおこなっているチーム全員が慌ててしまうと、普段なら絶対に考えもしないような手段を選んでしまう可能性があります。 それを防ぐためにも「どんな時に切り戻しするのか?」「切り戻しと判断したらどのような作業をおこなうのか?」の2点について、事前に徹底的に洗い出しておきましょう。
リリース計画を先に書く
「リリース日が近づいてきたタイミングで慌ててリリース計画書を書き始めて、結局最後まで書き終わらず、中途半端な状態でリリースを迎えてしまう」これはよくあるリリース計画のアンチパターンです。計画でもなんでもないですよね。リリース計画を書き始めるタイミングについては、プロジェクトの中盤くらい、だいたいリリースまでの作業の見通しがついたタイミングで、徐々に書き始めることを推奨します。リリース計画を書くことで「事前にやっておくべきこと・調整すべきこと」を整理するイメージです。
計画書という形でドキュメントに落とし込むことができれば、関係者に共有することで認識齟齬を防げます。「あ、リリースまでにやんなきゃいけなかったのに、この作業やってなかった!」みたいな凡ミスも、事前にやるべき作業をチェックリスト化し整理しておくことで防ぐことができるでしょう。
作業日当日のことだけしか書かないのはNG
リリース計画書とはそのリリース全体を俯瞰することができるドキュメントであるべきです。 作業日当日のことしか書かれてないドキュメントはリリース計画とは呼びません。単なる作業手順書です。 リリースを無事に完了させるためには、リリース日を迎えるまでに開発・構築・テストに加えて、その他様々な準備や調整が必要になりますよね。大規模なリリースになればなるほど、調整ごとは増えていきます。 そのような事前にやっておかなければならないタスクを洗い出して言語化・整理してスケジュールに落とし込むことこそが、リリースを計画するということです。リリース作業当日にやることは、作業手順書やタイムチャートとしてドキュメント化するようにしましょう。
誰が読んでも理解できる言葉遣い
どんなドキュメントにも言えることですが、関係者の間で認識のズレがあっては元も子もありません。特に関係者が多岐に渡る場合は、ちょっとした認識のズレが大きな問題を引き起こす可能性があります。 具体的な例を挙げると、リリース計画書のチェックリストに「Aサーバ -> Bサーバへの疎通確認を実施しました」と書いてあったとしましょう。これはL4レベルでの疎通確認(ping)をおこなったという意味かもしれませんし、L7レベルでの疎通確認(HTTPリクエスト)という意味とも読み取れます。もしこれがL4レベルでの疎通確認、つまりpingは打っていたけどHTTPリクエストは投げていなかった場合、443ポートが防がれていることに気づけずリリース日当日を迎え、疎通不可能で切り戻しする羽目になるかもしれません。(実際の現場ではこのレベルの問題は対策前進することが多いでしょう) このような認識のズレをなくすためにも、リリース計画の中では徹底して曖昧な表現を排除しましょう。
図を使う
考慮漏れを防ぐために図は有用です。プロジェクトメンバーが集まって図を見ながら気づいたことを言い合うだけで、想定していなかった課題に気づくこともあります。 おすすめは、リリースのマイルストンごとにどういう状況になっているべきかをひと目でわかる図を書くことです。Ph1の段階ではこういう状態になっていて、Ph2の段階ではこういう状態になっている、というような図を書くことで、認識合わせがしやすくなります。
思考停止でもリリースが終わるのが最高の手順書
リリース計画書の下位に位置するドキュメントとして、作業手順書があります。リリース日当日(あるいは事前作業)の作業を手順書に落とし込んだものです。 最高の作業手順書とは「何も考えなくてもコマンドをコピペすればリリースが完了する」ものです。 もしかするとエンジニアの中には「そこまでやる必要ある?見ればなんとなくわかるじゃん」と思う人がいるかもしれません。しかし、何度も繰り返しているように、リリース作業とは基本的に何らかの問題が発生するものです。小さな問題であればその場で解決すればよいのですが、解決策がパッと思いつかないケースもあるでしょう。 そんな時に「このままではサービス障害につながる障害になるかもしれない」「顧客に早く報告しないといけない(事業会社の場合は早く経営陣に報告しないといけない)」「リリース作業がおしていて時間がない」という状況では、どんな熟練のエンジニアでも普段と同じ精神状態で作業できない可能性があります。普段なら絶対おこなわない操作を実行してより大きな障害につながるリスクがあります。 リリース日当日の作業と違って、手順書の作成に時間をかけることができます。(もちろん落ち着いた精神状態で)リリース失敗する可能性を減らす為にも、手順書は「誰でも作業できるレベル」まで落とし込むことを推奨します。
可能な限り「対策前進しかない」状況を避ける
リリース計画の組み立ての話ですが、「対策前進(障害が発生した時に切り戻しをせずその障害をつぶしながらリリースを継続する)」しかできない状況を生み出す手順は極力さけるべきです。 「最悪切り戻すことでサービスへの障害を最低限に抑えることができる」状況と「もう進むしかない、死ぬ気で障害を解決しないとサービスを再開できない」という状況は天と地ほどの差があります。 もちろん「対策前進しかない」状況にならざるを得ないこともありますが、リリース計画を組み立てる上で極力こういった状況が発生するような手順を組まないようにしましょう。
押し引き判断の根拠を明確にする
「どんな時に撤退するのか」という撤退ラインについては、リリース計画の段階で誰が読んでも認識相違ないレベルで言語化しておく必要があります。 押す時は攻める、引くべき時は引く。ここを的確に判断し続けることで、負けの確率を極限まで減らすことができます。麻雀を例に出すと、勝つために必要なスキルとして押し引きの判断があります。その場の状況を俯瞰的に見て判断して押すべきか引くべきかを決めます。リリース時にもこの判断は非常に重要です。この状況になったら押す(リリース継続)この状況になったら引く(リリース中止&切り戻し)というのを想定できる限り洗い出しておきましょう。
コミュニケーションフローを明確化しておく
リリース日当日は、ただでさえ時間が足りなくなりがちなので、余計な作業はしないようにするべきです。当日慌ててSlackのチャンネルを作ったりするのはご法度。ちゃんとリリース計画の段階でコミュニケーションをフローを(はっきりと)明確化しておきましょう。 特に意思決定者を定義しておくのは大事です。切り戻し判断は誰がするのか、リリース判断は誰がどのタイミングでするのか、明確にすることで迷いがなくなります。
書いて満足しない
リリース計画を書いたら関係者に展開して説明しましょう。 できるだけ多くの人に見てもらい認識合わせをすることで、問題が発生した時の対処がしやすくなります。
(おまけ)リリース当日に大事なこと
本当に大切なのは、美味しいお菓子の差し入れと、雰囲気の出るホワイトボードと、前日たっぷり寝ることです。
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【サイトのご案内】 ■マネーフォワード採用サイト ■Wantedly ■京都開発拠点
【プロダクトのご紹介】 ■お金の見える化サービス 『マネーフォワード ME』 iPhone,iPad Android
■ビジネス向けバックオフィス向け業務効率化ソリューション 『マネーフォワード クラウド』
■だれでも貯まって増える お金の体質改善サービス 『マネーフォワード おかねせんせい』