1.無意味に高いサーバを納品した事件
これはエンジニア2年目ぐらいに担当した案件で起こった事件です。
何が起こったか
オンプレのファイルサーバ兼メールサーバのリプレイがあり、機器選定をしていました。
当時よく分かっていなかった私はとりあえず、「今のサーバの後継機でいいだろう」 ということで、設置してあったサーバの後継機・RAIDコントローラー・パワーサプライ・UPS等々をベンダーに見積もり依頼。
「まぁ高いけどこんなもんかー」 と思いましたが、
「今の稼働しているサーバの後継機なんで」 という説明をつけてお客さんに提出し、特に何も言われないまま発注しますという連絡が。
数週間後機材が届き開封しキッティング作業をしていると、先輩社員の方から以下の質問が
- 先輩社員:「ディスクのスロットたくさんあるけどこんなに使うの？」
- 私の答え:「ディスクは2つしか使いません」
- 先輩社員:「メモリのスロットたくさんあるけどこんなに使うの？」
- 私の答え:「メモリは1つしかスロット使いません」
- 先輩社員:「ちゃんと機器選定した？」
- 私の答え:「今設置してある後継機でいいかなと思ってました。」
- 先輩社員:「それはいけてないね」
- 私:「チーン」
得た教訓
- 事前に現在のサーバのリソース状況の確認をする
- 現在のリソース状況から最適な機器を選定する
- 後継機を候補に入れるのは良いと思うが、その一択ではダメ絶対
- 先輩社員に相談をする（これが一番大事でした）
- ちょうどいい案件で全てを私に任せてくれたので、1人でできる気になっていたのがいけなかった
2.LANケーブルについていた養生テープの番号を信じたらNW障害になった
これはエンジニア4年目ぐらいに起こった事件です。
何が起こったか
担当ではなかったが、フロア全体の上位に位置するNW機器のリプレイスがあるので立ち会ってほしいと言われました。
現場に到着し、まずNW機器に繋がっているLANケーブルをすべて抜いて、新しいNW機器に繋いでいきました。
そこまでは順調、しかしNWの疎通確認でインターネットに繋がらない問題が発生しました。
- 私たち:「NW機器の設定に問題はなく（事前に検証済み） なのに何故？？？」
原因不明のまま作業時間のタイムリミットが来たので、切り戻しを行ったが、まだインターネットに繋がらない状態は変わらずでした。
- 私たち:「チーン」
その後、応援が来てLANケーブルの繋ぎ間違えということが判明、繋ぎ変えたところ、インターネットに接続できることを確認しました。
繋ぎ間違えが起こった原因は、LANケーブルにタグが付いてなく、養生テープに番号が書いてありその番号通りのポートにLANケーブルを繋いでいたことが原因でした。
得た教訓
- 事前に現場調査をしっかりする
- 写真を撮って良いなら、LANケーブルがどのポートに繋いであるかを撮影し記録しておく
- 作業前も写真を撮る
- LANケーブルにタグがついていない場合はタグをつける（事前にできれば尚良し）
- 意味不明なタグやテープに記載してある番号は信用しない
- ダブルチェックをしっかりする
3.AWS ElasticBeanstalk環境でステージング環境デプロイ後、SWAPしたら本番環境を指定して、サービス障害が発生した事件
これはエンジニア10年目ぐらいに起こった事件です。
AWS Elastic Beanstalkとは何者？
Elastic Beanstalkとは、アプリケーションを実行しているインフラストラクチャについて知識を得なくても、AWS クラウドでアプリケーションのデプロイと管理を簡単に行うことができます。（AWSの公式ドキュメントより）
AWS Elastic Beanstalk とは?
Elastic BeanstalkのSWAPとは何者？
簡単に言うとElastic Beanstalkでブルー/グリーンデプロイをする方法となります。
Elastic Beanstalk を使用したブルー/グリーンデプロイ
何が起こったか
ステージング環境に最新のバージョンのアプリケーションをデプロイし、いつものように「ブルー/グリーンデプロイ」をするために、新バージョンで稼働しているEB環境と現行バージョンで稼働しているのEB環境をSWAPしました。
SWAPが正常に完了し、サービス確認をしている時に事件が発生しました。
サービス確認用のURLに接続すると、謎の証明書エラーが発生。
- 私：「ALBや証明書は何も変更していないのに、なぜ証明書エラーに？？？」
新バージョンで稼働しているEB環境の設定を確認したが原因が分からずに10分ほど経過したところで、一緒に作業し調査していた同僚から一言。
- 同僚:「本番環境URLに接続するとこちらでも証明書エラーが発生しています。」
- 私:「チーン」
もう一度、新バージョンで稼働しているEB環境の設定を見ると、SWAPする環境を間違えて 本番環境を指定していました。
図で表すとこんなイメージです。
急いで本番環境と再度SWAPして復旧することができました。
※ 10分ほどサービス障害発生
その後、細心の注意を払いながら、新バージョンで稼働しているEB環境と現行バージョンで稼働しているのEB環境のURLをSWAPをして、無事にステージングでサービス確認ができました。
得た教訓
- ダブルチェックをしっかりする
- 何度もやっている手順だが、ミスをするとサービス影響がある時は2回以上設定があっているか確認をする
- そもそも手動でやるからいけない？
- CI/CDで実行を検討する
- 今回の件のSWAP作業は本当に間違いやすいので注意が必要だと感じた
まとめ
結論としては以下になると思います。
- 事前にできることはやっておく
- 作業日までに分からないことをなくす（有識者に相談をする）
- ダブルチェックをしっかりする
この記事を書いている時に当たり前のことを当たり前にする 事が大事だなと感じました。
長文を最後まで読んで頂き、ありがとうございました。