22
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

あ、この現象、本やらアドカレで見たところだ!

Last updated at Posted at 2022-12-16

目次

・はじめに
・やらかす前に読んでいた記事
・アクセスログ分割シェル(初耳)壊れる
・エラーの原因とリカバリ方法
・このユーザいなり(書込権限)が入ってないやん
・やらかしました
・惨劇はなぜおこってしまったのか
・惨劇を起こさないためにできること
・お礼と感謝

はじめに

これからお話する事は2年以上も前の話なので、嘘をつくつもりはないのですが、事実と異なっている可能性もあります。ご了承ください。

やらかす前に読んでいた記事

上記がやらかす前に読んでいた記事です。
自虐か、読みやすさの自負か、小説のタグもついておりすらすらと読めました。オチまでついてて(見てる分には)面白かったです。
記事の内容、そして識者のコメントから当時の自分はホームディレクトリ配下のsshのパーミッションを安易に変えてはいけない。という事は理解できました。
しかし私の現場ではtmpフォルダを利用して作業する文化が出来ています。
「うちの現場ではtmpフォルダを使う文化があるので、そんなミスなんか絶対起きたりしない!(キリッ」とコメントを残したのでありました。

アクセスログ分割シェル(初耳)壊れる

該当の記事を読んでから半年以上経過し、時は2020年夏ごろ。
朝メールをチェックするとシェルがアラートを吐いていました。初めて見るアラートです。
該当シェルについてですがここではアクセスログ分割処理と簡単にお伝えしておきます。1つのどでかいアクセスログからユーザ毎にアクセスログを分割する処理を行っています。
初耳という言葉の通り、作成者から何も引き継がれてはいないのですが、そうも言ってられないです。

エラーの原因とリカバリ方法

シェルが抱える不具合はいくつかあったのですが、今回の話にかかわる原因だけに絞ってお伝えします。
根本的な原神はアクセスログ分割時の一時処理フォルダが共有ディスク上に設定されていたことでした。共有ファイルサーバはアクセス速度が遅いため、シェル実装当時は問題なかったのですが、サイト増によってその処理時間が増大し、後続システムがファイルを見に来る時間を超過してしまいました。
だったら、ファイルを見に来る時間を遅らせれば良いと思ったのですが、ユーザとの取り決めとかサービス要件定義書?とかそこらへんに書いてあるせいなのかそっち方面での対処には倒れませんでした。

根本対処としては、一次処理フォルダを共有からローカルへの変更。
が、それだけでは完全解決となりません。トラブル期間中の抜け落ちてしまったアクセスログを復旧させる必要があります。
修正シェルの検証も兼ねて検証環境にてアクセスログの復旧を行いました。

このユーザいなり(書込権限)が入ってないやん

検証環境で作成した分割後のアクセスログを本番環境のあるべき場所へ配置しようとした時のことです。
FTPで配置しようとしたところ、アクセスログの保存場所は参照権限はあるのですが、書込権限はないようで、アップロードができませんでした。これでは検証環境で作成した分割済のアクセスログを本番環境へ配置することができません。
一時的にパーミッション変更しても良いかと思ったのですが、本番環境なので安易に設定変更はできません。使えそうなアカウントを色々探した結果、作業用アカウントであれば利用できそうだったので、こちらで作業を行うことにしました。

そうして分割後のアクセスログを全てホームディレクトリ直下にアップロードが完了しました。後続処理で問題が起きるかもしれないので今のうちに所有者とパーミッションも変えておきましょう。
FTP操作時に他にファイルが無いことは確認できているので1コマンドでまとめて一気にやっちゃいます。
chown -R root: ./*
chmod -R 755 ./*
OK!完璧ですね。
あとはファイルをあるべき場所へ移動して…復旧完了です。くぅ~疲れましたwあとはこれを日数分行えば良いだけです。

やらかしました

そんな時に、ふともうひとつ窓が欲しいと思ってteratermマクロを起動したのですが、何故かサーバに接続できません。なにもしてないのにパソコン壊れた。
JP1では特にアラート発生なし。作業フロアに居た他の作業者も特に異常は無さそうに作業を継続しています。自分だけ…?おかしい…何かがあったに違いない…。一体何が…。
ここですごーーーく重要なのが、今自分が作業しているサーバ、ログ管理サーバなんですけども。これは踏み台サーバも兼ねてるという事です。SSHでどのサーバに繋げるにしても必ずそこを経由する必要があり、このサーバの作業用アカウントが利用できないとなると、それはもう本番環境のサーバに一切アクセスできなくなることと同義でした。

そこでタイトル回収と言いますか、おぼろげながら浮かんできたんです。上記記事の内容が。
幸いな事に「”もうひとつ”窓が欲しい」という事で、既に接続済のteratermがそこにはありました。三苫のゴールアシストの判定よろしく。首の皮一枚繋がっていたんです。ブラボー!
早速作業アカウントのホームディレクトリをls -laで確認したところ、予想通り。隠しファイルも含めてすべてrootユーザに変更されちゃっていました。ってなんでここにrootユーザ君が!?(補足しておきますと、アクセスログ分割シェルはrootユーザでcronで動作してたので、ファイルは全てrootユーザでできていたのでした。)
他のユーザを参考にしながら所有者とパーミッションをあるべき姿へ戻します。
そうすると無事teratermくんは繋がるようになりました。

自分の現場ではtmp配下で作業する文化が出来ているから大丈夫とはなんだったのか。
帰宅してから上記記事にて、やらかした事とこの記事のおかげで助かった事についての感謝をコメントしたのでした。

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

本項目はアドカレに投稿するに当たって必要と知り、後から追加したのですが、本項について考えた中で出てきたもの書いております。なので、上記では一言も出てこなかった内容もあり突拍子もない内容になってしまうことご容赦ください。

・緊急の障害対応(と思い込んで)で基本動作を怠ってしまった。
障害対応は時間勝負になりがち…。
しかし””本当に緊急だったか””というところについては確認の余地があります。当時は周りから本件について早急な対応のプッシュ等をされたことは一度も無かったですし(自分ではなく、自分の上長が別部署の人からプッシュされてるのは打合せの中であったけど。)部署内の認識として、これは急いで対応しないといけない。と共通のものとなっていたか。というところ、自分が勝手に「うーん、これはユーザ影響出てるから緊急w」みたいに思い込んでしまっていたのかなと思いました。
で、その勝手な思い込みからさらに「緊急だから仕方ない。」と自分に勝手に言い訳をして、基本動作(リモート全盛期というのもあったりして、一人で作業したりしてました。)を守れてなかったというところは、これでミスを防げたかどうかはわかりませんが、その後の後処理の部分で結構差が出るのかなと思います。

まとめますと
「絶対守ること!→自分の勝手な考えで急いで決められたルールを逸脱しない
 そのためには?→部署内で対応すべき課題に対して共通認識をもって進める。」
これです。
どこからともなくTwitterに謎のリプライが飛んできて、この言葉を100回音読して「言葉」ではなく「心」で理解しろ。と、やらかす前に言われていたら防げたと思います。
※特にどこからが自分の勝手な考えで、どこからが自分の勝手な考えじゃないのか。ミスしたから結果論でそう言ってるだけじゃないか!と単なる便利ワードと思う時期もありましたが、非常にわかりやすい形で「自分の勝手な考え」の定義を落とし込めたかなと思います。自分で自分を褒めたいです。 

惨劇を起こさないためにできること

①リスクを評価する
本番環境で勝手に設定変更をしてはいけないこと。という意識を持ちながら、結局はさらに危ない事件を起こしてます。ホームディレクトリ配下だし、ファイル操作だけだし…と本番環境の設定変更という意識をもってやってたわけじゃないので、正しいリスク評価をしないといけない場面に自分が居る。という意識を持てるようにするために、具体的な意識や行動をどうするか?というのは思い浮かばないけど、なんとなくそんな気はします。
②共通認識をもって作業や対応を進める。
自分も作業の合間に定期的な情報や進捗のアップデートはしてたつもりでしたが、作業進捗の共有だけじゃなくて、障害対応の優先度としての温度感とか、スケジュール感とか。そういうところ、しっかり共通認識を持つべきだったと思いました。
③忙しさや緊急という言葉を言い訳にルールを破らない。
忙しいから、緊急だから。といってルールを破らない。ミスを防げた防げないに関わらず、やらかしちゃった後に響くと思います。
③ホームディレクトリ配下でファイルを全指定で所有者や権限を変更しない。
そのまんますぎますが、同じミスを繰り返すのも良くないと思いますので。これはこれとして胸に刻みます。

お礼と感謝

本番環境でやらかしちゃった人 Advent Calendarで大事な事って。本来は起こってはいけないような出来事を、当時の記憶を引っ張り出し、胃の痛い思いをしながらあえてアウトプット、共有していくことで、同じ不幸な目に合う人が居ないようにしよう。っていうのが本質だと思います。
内容がやらかしというのもあり、性質的に批判や指摘のようなコメントも多かったりするのかなという不安もあります。皆さんもそうだと思います。
そういうところでまさに企画者、投稿者が期待した成果が得られたのではないかと思い、思わず声に出したくキーボードを取らせて頂きました(って割にはもう2年前だけど)

本当に本アドベントカレンダーのおかげで人生変わりました。ありがとうございました。

22
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
22
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?