More than 3 years have passed since last update.

オークファングループAdvent Calendar 2021

優しい忘却～知識紛失アンチパターンと戦う

Last updated at 2021-12-01Posted at 2021-12-01

はじめに

データや知識が紛失したことで発生した問題に対する事後対応をたくさん経験してきました。
これらは、いざというときに障害や質問として噴出しますが、そのフラグははるか前に用意されてきたものがほとんどです。
実際に起こった問題は、起こってから対応するしかありません。しかし、起こるかもしれない問題は、事前に検知することができるはずです。
メンバーの入れ替わりが多い環境であればなおのこと、知識紛失という最大のリスクに向き合うべきでしょう。

ここでは、私が体験してきた知識紛失アンチパターンと、その戦い方を説明します。
泣けるくらいのバッドノウハウもしばしばありますが、許してください。

「知識を共有する方法」についてはあえて書かず、「忘却に対応する方法」に特化して説明します。

アンチパターン

1. 退職・異動に伴うもの

情報の更新漏れ

実例

退職に伴うメアド変更漏れ
- 一定期間は退職者メアドが残る運用だと、すぐに検知できない
- 運用担当者が中身を見る権限がない場合あり
wikiサービス移行によりURL消滅し、リンク切れ
- データは移行されたが、書かれたリンクは残り続ける
  - 同じwiki内なら対応してくれるが、githubのリンクは追随してくれない

対策

退職・サービス移行のタイミングで調査・書き換えするしかありません。
特にサービス移行の場合、移行後に入社した担当者には手が付けられず、前の情報が何かすらわかるすべはありません。

裏ワザとして、サービス移行タイミングで過去ログを全部テキストやHTMLにして保存する方法があります。ウェブサービスを移行する場合、これはかなり有効な方法です。

個人アカウント運用

実例

外部連携サービスのアカウントが個人メアドで作成されている
- 退職時にパスワードのみ紛失
  - （´-`）.｡oO（そりゃ個人のパスワードだから）
- 機能は動くが、情報を更新できない

対策

これはかなり致命的です。
万一発生した場合は、退職時の引継ぎ内で網羅するしかありません。アカウント内にデータが保管されないタイプのサービスであれば、サービスを新規に登録したほうがいいかもしれません。
予防として、外部連携サービスで登録するアカウントを共有のものにするようにしましょう。

このパターンは開発者に自由に作らせているために発生していることが多いようです。案件開始時に、サービスのアカウントを作成して提供することで、防げる可能性が高いです。

権限漏れ

実例

退職者が担当していた稟議が、退職後漏れる
- えらいひと＝退職者が自分で処理していたため、誰も知らなかった
- 閲覧権限により、ほかの人も確認できない

対策

えらい人の上司を引っ張り出す しかない事例です。
エンジニアがやること？　と思うかもしれませんが、障害復旧のためには手段を選べません。

引継ぎ漏れ

実例

運用フローが消滅し、運用内でいい感じに直していたデータが直されず、データ不正が発生
- 引継ぎリストから漏れていた

対策

運用フローを可視化しておきましょう。最悪、運用担当者が全員退職しても、開発側で見れるようにしたいです。
もちろん、手動の運用フローをシステム化するのも選択肢の一つですが、手動になっている理由がそれなりに存在する 場合も多々あります。

2. 定期的な運用・セキュリティに伴うもの

セキュリティ強化に伴い締め出された

実例

Apple Developer Program
- 二要素認証が必須になったが、二要素認証をonにするためには秘密の質問に答える必要あり
  - 数年前に作ったアカウントは、パスワードはしっかり保管していても、秘密の質問までは保管していなかった
- しかも、二要素認証用デバイスが機種変更により消滅

対策

発覚後ただちにサポートに連絡しましょう。本人認証ができれば丁寧に対応してくれますが、Appleの本人認証は厳しいためご注意ください。
Appleの二要素認証用デバイスは会社の端末にしましょう。MacかiPhoneですが、機種変更などで失われたり紛失する可能性のあるiPhoneよりは、サイズが大きく置いておきやすいMacの方がオススメです。

パスワードだけを忘れた

実例

APIキーを発行したアカウントのパスワード不明
- API使用にはパスワードが不要のため、知らなくても動いていた

対策

アカウント作成時に、APIキー・ログインID・パスワードをセットで全部保管しましょう。
これはレビューでもチェックできます。新規APIを使うプルリクが上がってきたときには設定ファイルが変わっているはずです。最悪直接書かれている場合でも、見覚えのないURLが上がってくるはずなので、その時点でチェックするのが一番です。

いつのまにか有効期限が切れた

実例

突然有料課金していたAPI・サービスが止まる
- クレジットカードの有効期限が切れた！

対策

クレジットカードで課金しているリストを定期的にチェックして、請求元を特定します。
Apple Developer Programのように有効期限がある場合、そのサービス有効期限も記録しておきましょう。
気づいた段階で、次回有効期限日付の数日前に担当者Google Calendarを入れておくのも有効ですが、 その間に担当者が全員退社する可能性もある ため、バックアップにとどめておきましょう。

3. 不具合・人的ミスに伴うもの

物理的に消滅

実例

サーバーが壊れたことで、ソースコードが消滅した

対策

サーバー自体をバックアップすべきなのは当然ですが、デプロイフローの中で最新のソースコードを保管する、という回避策もあります。
実際、こういう問題が発生する環境ではバックアップが壊れることも想定しうるので……。

メールが埋もれる

実例

上記にあるような、有効期限切れ・問題発生の連絡は来た
- しかし大量に来るメールの中に埋もれていた

対策

フィルタを作るか周期的に検索するフローを作るしかないでしょうか。正直なところ、一番難しい課題かもしれません。
サービス登録用のメールアドレスと業務用のメールアドレスを分けるのもひとつですが、歴史あるサイトほど、 info@ のようなメールアドレスを継続利用していることが多く、しかもそこにスパムがやってきます。

メールアドレスを複数設定可能な場合、開発側のメーリングリストを追加してもらいましょう。開発側のメールは相対的に少ないはずなので、検知がしやすくなります。

テストアカウントで課金された

実例

テストのためにアカウントを使用していたら、多額の請求が来た
- そのアカウントは厳密なテストアカウントではなく「無課金の事例だけ使ってよい、テスト用の実アカウント」だった
  - 請求が来る事例を理解せずにテストしていた

対策

「テストアカウント」と銘打っているのはプラットフォームで公式に認められたものなのか、それとも運用上「テストするときはこのアカウントを使う」というルールでやっているのかを、厳密に区別することです。
特に新入社員にテストを依頼するときは、慣習を教え切れていないことが多く文字通りに解釈してしまうため、注意。

それでもダメな場合のリカバリ

ここまで手を打っても、問題は発生します。発生した問題を最速で潰すために、これだけの方法が使えます。

人に尋ねる

当事者がいなくても、当時かかわっていた人が断片的な情報を知っている可能性があります。特にメール系の場合、当時の在籍者しか電子データを持っていない可能性が高いので、真っ先に確認しましょう。

メール・チャットの履歴を追う

今体験した事例は、過去にも一度起こっている可能性があります。その時の処理が記録に残っていれば、そのまま使えます。一般的に、大急ぎで対応したときの作業内容ほど、ちゃんとしたドキュメントに残っていないものなので、対応完了後にドキュメント化することを忘れないでください。
「二度あることは三度ある」ですから、絶対に同じことはもう一回発生します。

過去の作業資料を追う

チャットのログ、社内wiki、チケット制の作業管理の場合はRedmine、サーバー構築の場合はhistory コマンド……など、過去資料は意外なところに残っている可能性があります。
場合によっては紙媒体や契約書、長くからいる人のメールボックスに残っているかもしれません。

おわりに

人間社会に必ず忍び込む「優しい忘却」に立ち向かうのは大変ですが、一番の勉強になる案件です。~~あまり大きな声では言えませんが、謎解きのような中毒的な楽しさもあったりします。~~
高度なシステムであっても、アカウント管理やクレジットカードの課金からは逃れられません。おそらく、どの環境でも役立つノウハウではないでしょうか。
動かなくなったシステム、誰も知らないシステムと戦うときに、これらの手法が役に立てば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up