概要
そんな状況来ないのが一番。ではありますが時が流れる以上、廃れてしまうときが来てしまう。
廃れないまでも、運用する人の都合でサービスを続けられなくなってしまう時もある。そんなときは
- 運用していたサービスを別のチームに任る事になる
- サービスを別の方々に引き渡すことになる
ということになりますね。
たまたまそういうサービスに立ち会いまして、色々知見がたまりました。
上手くできないこともありましたし、反省も兼ねて次はこうしたいなぁ。という気持ちも込めてまとめてみました。
Step0 まずは引き渡しあとのフォローする範囲や引き継ぐ人を明確にしよう
引き渡しあとのフォロー範囲
引き継ぎ元の方々の手を離れるわけですから、そりゃすぐには今まで通りの運用は無理です。
もともと５分で対応できていたことが、引き継ぎ先の人たちだと４０分かかるようになったとか。
そのとことチクチク引き渡し先に突かれても互いに不幸なので、こういう不具合や、こういう作業はいつまではコチラで引き受けます。サポートも〇月〇日までは引き受けます。
と、きちんと決めましょう。
引き渡す人と引き継ぐ人を決めよう。
ここがふんわりしたまま引き継ぎ作業が進むと大変です。
引き渡す側は普段使っているマニュアル、デプロイフロー、インフラ内容、アプリケーション運用方法などをスムーズに引き渡せるように準備しよう。
引き継ぐ側は不安点などがあれば予め列挙し、渡された資料は早めに一読し、サポート期間内にできるだけ触っておくとサポート期間が終了後でもかなりさわれる状態になることが出来ると思います。
伝えることはめちゃくちゃあると思うので、誰が渡して、誰がもらうのか。これはすぐに決めるべきです。
Step1 開発環境・インフラを引き継ごう
何を引き継ぐべきかもう少し深ぼってみたいと思います。
インフラを引き継ごう
サーバー周りに関しては構成図などの資料を引き渡し、現状稼働している内容のものを伝えましょう。
AWSなどクラウド管理しているなら、閲覧権限のみのアカウントでもさくっと作って中を見てもらいましょう。百問は一見にしかずです。
もしクラウドで管理してるとなると構成内容によってはお金もガッツリかかることになります。サーバーのコスト感も伝えて、最初はテスト環境などは止めてほしいとか要望があればその時点で聞いておくのもいいと思います。
開発環境を引き継ごう
Chef、itamae等のプロビジョニングツールの使い方。もしくはdockerを使った開発環境の構築の方法ですね。
ここは万が一詰まると手ほどきが大変なので、もし対面で話す機会があればそのときに構築だけはやってしまうといいですね。
早い段階から環境に触れることで、不安も打ち消せるし、引き継ぎ期間ならサポートを受けながら勉強できるし、勉強してもらえれば此方の負担も減るしWIN-WINです。
なる早でやりましょう。
Step2 デプロイ方法を引き継ごう
可能なら簡単な修正を実際に行ってもらって、本番へデプロイする手順を実施してもらいましょう。
勿論、ドキュメントに残して渡すことも大事ですが、サポートなしの状態でデプロイは万が一が怖いし不安も感じると思います。
互いに事故防止をする意味でもやっておきましょう。
Step3 過去起こった障害や、監視ツールを引き継ごう
過去の障害対応
これは車輪の再開発防止だけでなく、相手側に「既にバグとして顕在していたやつかどうか」の判断を素早くしてもらうためにも大切です。
知っていたのに黙っていた。なんてのは最悪です。引き継ぐ人は疑念を抱きますし、都度念入りに確認しなきゃいけないという状態にもなってしまいます。
不幸なすれ違いを回避するためにもやっときましょう。
監視ツール系
エラー検知や、ログ監視、死活監視など普段使っているツールが有ると思います。
ただ、現在使っているツールと相手側の使っているツールとは違う場合がありますので、早めに打ち合わせて乗り換えていかないと大変です。
可能なら、引き継ぎ側がサポートしている間にさくっと対応してしまえるならそのほうが後のトラブル防止になったりします。
Step4 ドキュメント・マニュアルや復旧方法例を引き継ごう
ドキュメント・マニュアル
最低限Step3までやっとけば、引き継ぐ側が色々触れるようになり始め、わからない点を質問したり、疑問点をまとめたりしてくれると思います。
その回答と並行して、システムを構築するにあたってバラけているドキュメントなど整理したりしましょう。
もし既にまとめてあるならStep1とかでやってしまってもいいのですが、おそらくこのタイミングでもまたドキュメントの手直しが発生すると思います。
なぜなら、内情がわかっている側がまとめたマニュアルだと、引き継ぐ側が本当に知りたかった項目というのが漏れたりするからです。
どうせ追記する可能性があるなら、綺麗にまとめたりするのはこのタイミングでも問題ないです。
復旧方法例
サポート期間終了後になんかよくわからんがシステムがダウンした！！
という場合に、引き継ぎ側がすぐに原因を特定できればいいのですが、そうじゃない可能性もあります。
そうならないために、ロールバックの方法であったり、また1からシステムを構築する復旧方法は用意しておくのが良いです。AWSならAMIイメージを用意して、立ち上げるだけでとりあえずは動くようになるとかですね。
Step5 ツールのアカウントやサービスのソースコード。issue・bugを引き継ごう
アカウント
AWSやgithub、監視ツール系などなど、もしそのままスライドして使い続けるサービスがあれば
- いつ引き継ぐのか
- ツールを利用するための費用は引き継いだ後どう支払いするか
- 引き継ぎ側の誰がツールを管理するのか
- パスワードなど重要情報はどうやって渡すのか
- そもそも引き続き使うのか。いらないなら解約するのか。
など早めに相談して、手はずを整えておきましょう。お金が掛っているサービス系は結構引き継ぎが面倒なので注意が必要です。
ソースコード
git管理していれば割とかもしれないです。
が、例えば
- リポジトリを新しくして、過去のissueやpull requestなどは引き継がないようにしたい
- GithubからBitbucketにしたい
など、そういう要望があると思います。
早めに確認して、どのタイミングで移行するのがベストか決めておくと良いですね。
issue・bug
過去の障害対応について引き継ぐのと似ていますね。
既にわかっている範囲でbugやissueなどは引き継ぎましょう。
あとからbugじゃないか！と怒られてもお互いに不幸です。
Step6 よくある作業や、イレギュラー対応などを引き継ごう
人の手で定期的に行っている作業があれば忘れずに引き継ごう。自動化出来ない何かしらの理由が存在しているわけだし、仕方ない。
あとは、イレギュラー的な対応なんてのは存在していませんか？ 頻度は少ないけど、たまに起こってしまう対応も忘れず伝えましょう。
暗黙知の排除、発掘
長年運用しているサービスだと、気づかぬうちに暗黙知としてしまっている事があると思います。
これを気に、「あ、誰にも伝えてないけどこういう事やってた」っていうのは徹底して排除しよう。
ずっとやっていると気づきにくいかもしれないですが、この辺りは意識して伝えるようにしましょう。
Step7 保守する上でwikiとかtipsがあれば引き継ごう
マニュアルやドキュメントではないが、よくつかう技術を伝えておくのもいいと思います。
- このシステムを使う上でちょっと特殊な技術
- 開発していればぶつかるであろうわかりにくい部分
- 知っていれば楽に開発が進む部分
そういうのも伝えましょう。感謝はされど嫌がられることはないと思います。
Step8 懸念点を引き継ごう
- こういうアイディアがあって、こうしたら良くなるけど時間がなくてやれなかった
- 顕在化していないバグだが、システム的にこう舵切ったらヤバイ箇所ある
など、相手に予め教えとくだけでも幸せになれます。もし、こうなっていたら。というのは長年サービスを使っていて感じる「勘」のようなものは割と大切だと思います。
終わり
ぼくが引き継ぐにあたって行って良かった、行えなかった反省が以上になります。
勿論これ以外にも細かいところで諸々動いたりはしましたが、大枠はこんな感じです。
こんなに時間取れねーよ！とか、他にもやることあるだろう！とかあると思いますが、そのへんはよしなに改変して使ってもらったり、コメントしてもらえると助かります。
それでは、お役に立てばなんとやらです。