Help us understand the problem. What is going on with this article?

いつものように本番作業してたはずなのに

この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019」の1日目です。
https://qiita.com/advent-calendar/2019/yarakashi-production

なかなか濃いラインナップが期待されますが、まずはさらっといきたいと思います。
具体性が乏しい部分もあると思いますが、そこはお察しください。。。

やらかし

背景(前提条件)

  • いっていに昔の話です
  • ETL(データ加工)サーバ
    • 数十を超えるシステムからデータを集める
    • BIツールなどで活用できるように各種加工処理を行い、DBなどにロードする
    • 繁忙の違いはあれど、24/365で常時一定量の処理は稼働している
    • 複数のチームが共存しているサーバ
      • アプリ面では比較的疎
  • ETL処理のリリース前に本番サーバ上で試験をする取り決めになっていた
    • 性能や本番相当データのテストが安全に行えるような環境が(当時は)存在しなかった
    • 修正リリースの場合、当該処理が動かない時間帯を狙って試験を行う(当然)
  • 私はアプリチーム

問題編(経緯)

  • ある日、チームメンバ(Aさんとする)がいつも通りの修正リリースすることを承認し、作業自体は任せていた
    • よくある修正で規模も小さく、局所的な対応のため、いつも通りやっといてください、という形で
  • しばらくすると、隣のチームの電話がなった。定常ジョブが10以上複数エラー終了したと連絡あり。
  • そのとき自分は時間も権限もあったので、軽い気持ちで「ジョブ見ますよー」と言って、作業部屋に移動。
  • SSHログインしたものの、ほとんどのコマンドが通らない。
    • cdは通る。lsやそのたツールのコマンドが通らない
    • この時点でいやーな予感はしたが。。。
  • すると他のチームメンバの電話もバンバン鳴り出した。ジョブが落ちまくっているらしい。だが調査もできないので焦りが増していく。。

さて何が起きたでしょうか、、わかる人はわかるのでは。。。

その時の思考と行動

  • あれ、コマンド通らないのか、なんでだろ。しかも一部?
  • 急にドカンドカン落ちるのか、ハード系障害かなあ、流石に影響範囲広いし
  • そういや何やってんだろ、Aさん〜
    • Aさん「試験できなくなっちゃって、いったん障害対応優先ですかねー」
    • 自分「そうっすねー、どこまでやったんですか?」
    • Aさん「ちょうど試験用に共通ユーザの環境変数を書き換えたところです、試験用のモジュールを置く場所決めて、別途読み込めるようにしたんですけどね」
    • 自分「なるほどー。。。えっ何それ」
    • Aさん「.profileのPATHを直接書き換えましたよー」
    • 自分「…それやん絶対。。。」

原因

  • バッチ処理が使っている共通ユーザの.profile手動でエディタで 書き換えた
  • その際、PATHのあるある間違いをやってしまった
#(修正前)
export PATH=$PATH:/app/bin
#(修正後)
export PATH=/home/xxx/work_test/bin
  • 結果バッチ処理含め大量にエラーが発生

対応

  • 部屋全員に「動くな!」と叫ぶ(logout禁止)
  • lsなどが通る、修正前のprofileでログインしている人を探した
  • その人のターミナルを大事にして、.profileを元に戻した
  • 周知し、ジョブの再実行大会を促す
  • やってたリリース作業は延期。

ということで、以下は本アドベントカレンダーの必須項目です

振り返り

惨劇はなぜおこってしまったのか

  • 普段の手順と変わっていたことに気づかなかった
    • 今までは本番のモジュールを上書きして手動テストしていた
    • Aさんは上書きよりも別場所においてテストしてから、確認済みのものを上書きすれば良いのでは?と考えた
    • 考えて工夫した結果ではあったが、裏目にでた
  • 本番に手をいれる作業についての影響を甘くみていた
    • その作業が他の何に影響を及ぼすのか、ということは常に考えないと、本番環境だから。。。
      • 個別モジュール上書きだけなら自分のチームしか最悪落ちないが、、
    • 特にエディタで直接編集する、のようなアドホックな(ヒューマンエラーが混入しやすい)手順になっていた

二度と惨劇を起こさないためにどうしたのか

  • ヤバイファイルはカジュアルにさわれないように権限制御
    • アプリチームが触れないroot管理に
  • 経緯をまとめてグループ内へ周知、教育
    • 個人的に、新人などには影響ないところでPATHエラーを踏ませたりして、身をもって学ぶようにさせた
  • その他(人の力で回避。チェック強化とか。。。)

終わりに

  • 設計時にどの程度機能分離するか、やリリース時の手順をどうするか、などを考えるときに毎回思い出します
  • 結局のところヒューマンエラーなので、仕組み化、自動化などで人の手をできる限りかけないようにするのが本質的には良いとは思います
    • 今の時代なら、安価・容易に、クラウド、各種サービスなどの組み合わせ、すなわち技術で解決できる、解決すべきである、と思います

以上です。。2日目以降も楽しみにしています!

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away