「これ、誰が見てるんですか?」と聞かれて、答えられなかった。
開発会社からシステムを引き継いだ直後のことだ。本番で動いているAWS環境の面倒を、自分が見ることになっていた。でも、自分はAWSの知識がほぼゼロだった。
「クラウドインフラ」という言葉と、「一番有名なやつ」という認識しかない。それなのに、稼働中の本番環境の責任だけが、先に自分のところへ来ていた。
責任だけが先に来る、という状況
引き継ぎというのは、きれいに知識が渡されてから責任が移る——わけではない。
現実は逆だった。責任が先に来て、知識は後から自分で埋めるしかない。動いているシステムは待ってくれない。ユーザーは使い続けている。その上で「中身がわからない」という状態に放り込まれる。
このときの恐怖は、3つあった。
1. 本番で障害が出たらどうするか
一番怖かったのはこれだ。何かあったとき、自分は何もわからない。エラーが出ても、それがどこの何の問題なのか切り分けられない。本番環境で不具合が出る場面はあって、そのたびに知識ゼロで対応を迫られた。
「動いているうちはいい。壊れたときに終わる」——その緊張がずっとあった。
2. 構成が誰にもわからない
引き継いだ環境がどう組まれているのか、社内に把握している人間がいなかった。開発会社が作ったまま動いている。どのサービスが何のために使われ、どう繋がっているのか。ブラックボックスだった。
「これ、誰が見てるんですか?」という問いに答えられなかったのは、まさにこの状態だったからだ。
3. コストの不安
毎月の請求額が何にいくらかかっているのか、わからなかった。使っていないリソースがあるのか、無駄が出ていないか、事故的に高額になることはないか。お金の面でも、ブラックボックスは怖かった。
まず全体像を一冊で叩き込んだ
闇雲に検索を繰り返しても、知識が繋がらない。目の前のエラーだけを潰しても、次に何が来るかわからない。
だから最初に、運用の全体像を一冊で叩き込むことにした。監視、ログ、セキュリティ、コスト——運用とは何の要素の集合なのか、という地図を頭に入れた。この「最初の地図」があったから、その後に個別の問題を調べるときも「これは監視の話」「これは権限の話」と位置づけができるようになった。
（このとき読んだ本のレビューは「AWS運用入門」を知識ゼロで引き継いだ自分が読んだ正直な評価に書いた。）
あとは、見て触って調べての繰り返し
地図を手に入れたら、あとは歩くしかない。
やったことは単純だ。コンソールを開いて、設定を見る。触ってみる。不具合が出たら調べる。これをひたすら繰り返した。泥臭いが、これ以外に体で覚える方法はなかった。
地味な設定こそが効いた
この過程で気づいたことがある。派手な機能より、地味な設定の方が運用では効くということだ。
たとえば、ログをどこにどれだけ残すか。アラームの閾値をどう決めるか。権限を誰にどこまで与えるか。こういう「地味で、最初は重要性がわからない設定」が、後になって効いてくる。
障害調査のとき、ログがちゃんと残っているかどうかで天と地の差が出る。権限設定が雑だと、後でセキュリティの不安になる。最初は「こんな細かいこと」と思っていた設定が、運用を回すうえでの土台だった。
派手なアーキテクチャの話より、こういう地味な部分を一つずつ潰していくことが、ブラックボックスを少しずつ自分のものにしていく作業だった。
今も、完全にはわからない
正直に書くと、今でもAWSを完全に理解できたとは言えない。
新しいサービスは次々出るし、自分が触っていない領域はまだたくさんある。「これなら完璧に回せる」という日は、たぶん来ない。
でも、引き継いだ直後の「何もわからない」とは違う。少なくとも、何かあったときに「どこを見ればいいか」はわかる。地図があって、歩いた経験がある。それだけで、あのときの恐怖はかなり小さくなった。
同じ状況の人へ
知識ゼロで本番環境を引き継ぐ——この状況は、本当に心細い。責任だけが先にあって、知識が追いついていない。
でも、振り返ると乗り切る順番はシンプルだった。まず全体像という地図を持つ。あとは見て触って調べてを繰り返す。地味な設定を一つずつ自分のものにする。完璧を目指さない。
「何もわからない」から始めても、地図と手を動かす時間があれば、少しずつ恐怖は知識に変わっていく。あのときの自分に、それだけは伝えたい。
関連記事: