先行リリース…？ @MA-fn
この記事は「本番環境でやらかしちゃった人 Advent Calendar 2020」の12日目です。参加できて嬉しいです。
https://qiita.com/advent-calendar/2020/yarakashi-production
※この話はフィクションです。また、派手な内容ではありません。
はじまり
AM8:35
私は某ソフトウェア開発会社でシステムのヘルプデスクを担当している。いつも通りに出勤し、パソコンを立ち上げ、問い合わせメールがないかチェックする。
正確には「開発以外担当」である。体制図にも文字通りそう書いてある。開発担当が「開発の要件が決まってから商用リリースまで」を、開発以外担当が「それ以外」をやる。ユーザニーズをまとめて開発内容を整理するのも「以外担当」であるし、開発担当が作ったバグも、リリース後ならお客様対応含め「以外担当」がやる。あなた方に瑕疵担保責任という概念はないのか、といつも思う。
…話が逸れた。メールを確認すると一件引っかかる内容があった。
（昨日の20時…『システムから出力したExcel報告書のレイアウトが一部崩れている』。そんなこと起きるかなぁ。先週末システム更改してたけど、ここの機能触ってないし…）
システムは定期的に改版している。先週末リリースしたばかりだか、今も次版にむけて開発中だ。コーディング中だったはずだ。
ぼんやりしながらメールの添付を開く。確かに一部崩れている。
（あーこれ、レイアウトが決められないって開発担当が散々騒いでたやつだ。崩れているっていっても、そこをJavaで描画するから、フォーマットとしてはこれで正しいんだよね・・・あれ？これって今コーディング中・・・のはず・・・）
AM8:40
先週末のリリース資材を展開して中身を確認する。該当のフォーマットは次版用になっている。つまり本番環境に、開発中の資材がリリースされている。
（開発対象フォーマットはあと２つあったはず）
それらもまた次版用になっている。フォーマットが崩れたままのところを見ると、描画のプログラムはリリースされていない。何がどこまでリリースされたのか、さすがにすぐには分からない。そもそもリリースリハーサルも資材チェックもやっているはずなのに、なぜこの状況なのか。
AM8:55
担当の課長が出社してきたので、一報を入れる。
緊急会議
AM9:05
緊急会議が開催される。開発リーダが「トラブルに巻き込まれた」と文句を言っているが、いつものことだ。メンバは皆神妙な表情である。
現時点の私の調査状況を報告する。開発メンバには、リリース資材にどれだけの開発中資材が入ったのかの調査にあたってもらう。調査完了後即、終わらなくても1時間後に、集まることを決める。
AM10:00
会議。対象は報告書フォーマット３つのみと判明。対処は、本番環境に該当ファイルを配布するだけでよい。もしWebアプリ側資材も入れ替えが必要な場合はサーバ再起動が必要なのだが、ユーザの業務が完全に止まるので気安くはできない。今回はファイルの置き換えのみなので、システムを止めず昼間作業も可能だ。早速手順作成と検証に着手してもらう。
あとは、この問題がどこまでユーザに影響があるかだ。問合せ元はユーザ側のシステム担当なのだが、聞くと、この業務をやっているところはまだないはずとのこと。おそらくシステムを使った業務運用を検討するなかで、該当機能を使ってみたのだろう。
検証担当以外で、状況を整理する。本番リリースリハーサル後、開発以外要件で設定ファイルを修正したとのこと。もう一人の「以外担当」が作業をやっていたのは知っている。その修正分をリリース資材に入れるために資材を作り直し、その時に開発中資材も入ったらしい。
PM12:30
何とか検証を終え、本番環境への対処が完了。問合せ元には「対処したので確認お願いします」と連絡。
起きた原因
PM13:00 なぜおきたか。
会議。発生メカニズムを皆で整理する。
資材管理方法
ツールはSubversionを使っている。構成はこうだ。
私の感覚だが、まずありえない。初版開発とか、2、3人で開発してますならまだしも、結構な人数が並行開発ありでこれを触っている。知ってはいたが、やれてるならそれでいいし、問題提起すると責任者&実行者にさせられるので、正直タスクを増やしたくなかった。「以外担当」は開発「以外は全て」を受け持つため、常にやることだらけなのだ。
あとで開発メンバ（外注企業）に聞くのだが、口々に「おかしい」という。じゃあなぜそのままなのか。明確に回答はなかったが、恐らく「何も言われないのだから、自分たちからわざわざいうは必要ない。従っておけば自分たちの責任にはならない」と思っている。多分私の推測は当たっている。というか、私自身にも当てはまる。
作業の時系列
① 次版の資材をコミットしたのは新規メンバとのこと。資材凍結後であれば、次版分をコミットしていいと考えたのだろう。前からいる人は、商用リリース終わってしばらくたつまでコミットしないらしい。素晴らしき運用ルールに今まで守られてきたのである。
② のファイル修正だが、アプリとは関係がなく設定変更だけだったため、本番での作業後のコミットとなった。そのやり方でいいのかという問題はある。
③ 資材の再作成を実施した。WAR再作成は行わず、設定ファイル（フォーマットファイル）類の再作成のみ実施している。
資材チェックですり抜けた原因
資材再作成後、再度資材チェック（本番にあげるのはこれでよいか）を実施している。
warファイルの中身は厳密に確認実施（Subversionのログ、Classファイルの変更がないか、等）
フォーマットファイルは今回の開発対象外だったのでチェックしていなかった。
これは、大きな意味でだが、『開発あるある』だと思っている。修正した箇所の処理はテストするが手を入れていないところは注目しない。他の箇所の修正によって、手を入れていない箇所が要件を満たさなくなったことに気づかなかった事例を時々見る。修正箇所にフォーカスが当たり、全体を見ていないのだ。
最後に、課長から、今回の経緯と対策をまとめるよう指示される。
（私は見つけただけなのに…）
PM13:40
問合せ元から、確認しましたOKです、との回答。
問題が起きないために
PM15:00 起こさないために
時系列をまとめ、今後の対策を整理する。
構成管理
開発メンバにヒアリングし、この形を取った。
ちなみに、過去いたプロジェクトでは、以下のような形式でやっていた。とある製品（有料）を使っていた。
有料だからかものすごく融通が利き、複数拠点、並行開発、複数サブシステムもしくじりなく管理できていた。随分昔の話だし、構成管理ツールにお金が払えて、構成管理専任の担当が置けるくらいの規模のシステムだったが。
個人的にはこの形が好きなのだが、Subversionではできなさそう（工夫すればできる？）だったのでやめた。
資材チェック
- Subversionからリリース資材を作る際、盛り込み内容（チケットなど）の確認を行う（今まで通り）。
- リハーサル資材と商用リリース用資材の比較は全数やる。
基本動作はしっかりとね、程度のまとめではある。チェックの方法など細かいことも議論し、会議終了となった。
そして、「構成管理のルール策定」と「構成管理方法の段階的変更」というタスクが増えた。
翌日
ユーザからあれ以降の問い合わせはなく、本件の問い合わせ対応としては終了となった。
この後の社内／社外対応については記載を控えるが、その瞬間のリカバリよりも事後対応の方が何十倍もしんどい。原因分析、再発防止対策などを行い、丁寧に謝罪、説明しなければならない。
本当にすべきこと
難しいが、チームの雰囲気改善だと思う。このシステム／開発プロセス／チームを良くしたい、と思えるかどうかなのではと思う。
互いの責任範疇を主張し合い、互いに無関心であるならば、何も始まらない。一人だけ、一部だけが良くしよう奮起しても疲弊する。疲弊してでもやり切る情熱があるか、全体が協力する方向に向かない限り、改善は進まない。少なくとも、私にその情熱はない。
まとめ
- 構成管理は間違いを『起こさない仕組み』にしよう。運用ルールでカバーする範囲は極力狭くしよう。
- 修正箇所だけでなく、システム全体をみよう。プログラムを修正することが目的じゃなくて、お客様要件を満たすことが目的だよ。
- 契約形態とか関係なく、意見が言い合える組織風土を作りたいね。
最後に
長文にお付き合いいただきありがとうございました。
| 引用元：https://qiita.com/MA-fn/items/ebd58b5dea219e880be3 |
単語メモ
- Subversion（SVN）：オープンソースバージョンの管理システムです。ソースコードやドキュメントを管理するのに用いられます。
- WAR（Web Application Archive(Servlet)/ヲー、ダブリュエーアール）：作成されたアプリケーションを一つのファイルにまとめ、パッケージとして圧縮する形式です。
- ブランチ(branch)：木のように枝分かれした構造のデータ集合などにおいて、要素間を結ぶ繋がりの事をさします。
- トランク(tunk)：通信ネットワークの分やで、複数の回線やポートをなどを束ねて複数の端末や利用者で共有するものの対象をさします。