気をつけて設定ファイルを書き換える
- 面倒な分、やると得になるシリーズ
- 長いので、心に余裕があるうちに読むのをおすすめします
- ちゃんと伝えられていなくてごめんなさい、書きました
- 編集は大歓迎です(wikiは編集履歴が残るので失敗しても大丈夫)
心得を読む
- 説教チックかもだけど本当に気をつけるべきなのを理解してほしいです
基本技
- 落ち着く
- もし失敗しても、起こってしまったことは仕方ないので、焦ってさらに壊したりしないようにする
- キーボードから手を離して深呼吸する
- 複数人で作業する
- 作戦を相談する
- こうしようと思っているけど、合っている？とか
- 打ち込むコマンドを相談してから打ち込む
- 無理だったら作業を他の人に任せる
- 状況の説明だけして、実際にはその人に打ち込んでもらうとか
- 作戦を相談する
- 休憩する
- ぶっ続けで直すのが偉いわけではなくて、直ったら嬉しいのだから、気合いでやったりしない
- これだけやって休む！とか思ってしまったら、それをやる前に休む
- 休憩に向けて思考が止まりかけていて、大抵失敗するので、それはせずに早く休む
作業ログを残す
- 複数人でやるなら、複数人編集ができるものを使うとよい
- Google Docs とか HackMD とか VSCode の複数人編集機能とか
- 時刻、やったこと、やった内容、やった場所(サーバ、手元のPC、ディレクトリパス)、見たファイルのパスなどを事細かに書く
- 細かすぎると思うくらいがよい
- 実際細かすぎるときもあるけど、情報が少なくて困るよりよっぽど良い
- 細かすぎると思うくらいがよい
バックアップをとる
- とり方は様々
- バージョン管理をする(git など)
- ルート権限が必要なときは面倒なので、ちまちま↓をやるのがよい
- バックアップファイルをつくる(cp hoge.conf hoge.conf.201904131148 など)
- バージョン管理をする(git など)
- できれば別の環境にもバックアップする
- できるだけ細かい単位でとる
- ファイルごと、変更1行ごとなど
- 差分がわかりやすいので、原因がわかりやすいし、戻したりしやすい
- できるだけ単純な履歴で残す
- 時系列がよさそう
- 自分の思考をトレースできるので
- ファイルの変更時刻などはアテにしないで、ファイル名に日時をつけるとよい
- 間違えて編集してしまっても安心
- 名前順で並ぶので大抵見やすい
- git など使っていたら多少複雑でも管理しやすい
- 時系列がよさそう
- 変更箇所にコメントを残す
- 何のために何から何に変えたか書くと、後で見たり他の人が見たりしたときにわかりやすい
- 後で、は下手すると10年とかになったりする
- 何のために何から何に変えたか書くと、後で見たり他の人が見たりしたときにわかりやすい
失敗のときどうなるか/どうするか考える
どうなるかパート
- 書式エラーだとそもそもサーバが止まったり起動しなかったりする
- OSの設定などを書き換えてOS自体が起動しなくなったりすると、直す術がとっても少ないと思うので、めちゃめちゃ気をつける
- httpサーバくらいなら、失敗してもページが見えないくらいで済むし、バックアップファイルに戻したら大抵状態を元に戻せる
- データが消えたりすると戻せないので、そういうときはやっぱりめちゃめちゃ気をつける
- メールサーバだと、連絡したのに届いていないなどになる
- でも連絡主の側に文書は残るので、データが消えることはなさそう
- 失敗かどうか、すぐにはわからないこともある
- 不定期な事象でエラーになったり
- OSが古くなってパッケージを配布するサーバが消え、パッケージが落ちなくなってエラーになったり
- 誰が困るか
- 自分だけならとりあえず気軽になれる
- 部内の人が不便するくらいなら、謝って協力してもらいながら直せるのでまだ気軽
- 部外の人が不便すると結構気まずい
- 原因含めてメールで伝えて謝るとかすることになるかも
- 教職員、学外の人が不便するとめちゃめちゃ気まずい
- セキュリティホールを作ってしまったりすると、大学のネットワークやインターネット全体に影響するかも
どうするかパート
- ちゃんと変更が反映されているか確認する
- ファイルを保存しないと反映されない
- 反映操作が必要な場合もあるので注意する/反映方法を調べる
- hogehoge reload のような反映コマンドを打たないと反映されないとか
- 毎時0分に読み込まれて反映されるとか
- 他の人にも試してもらったりする
- バックアップファイルに戻せば状態が元に戻るなら、そうする
- 何がいけなかったのか考える必要があるので、失敗したファイルも残しておく
- git なら revert など履歴の残る戻し方をする
- やっぱり合っていたときに、さらに revert できる
- git なら revert など履歴の残る戻し方をする
- 何がいけなかったのか考える必要があるので、失敗したファイルも残しておく
- 状態が元に戻らないなら、バックアップファイルを参考に、失敗状態から回復させる
- とりあえず連絡する
- "なんかおかしい" だけでも、まず Slack やメールに書くと、把握していることがわかって安心できる
- そこから、何がどうおかしく見えているかわかったらそれも随時書く
- 原因はわからなくても、これが動いていないとか、このエラーが出てる、とか
- 原因がわかったらそれも随時書く
- できれば回復方法/予定とかも書く
- いつまで困るのか知れると不安が少し減る
- できれば事象と予想は分けて書く
- 何が起こっているかは正確に書く、そこからの予想は間違っていてもよい
- 予想は間違っているかもなので、少なくとも事象だけは正しいようにする
- 他の人が正しい予想をできるかも
- 予想は間違っているかもなので、少なくとも事象だけは正しいようにする
- "こういうエラーログが出てる(コピペ)" は事象、"このエラーは多分さっき書いた設定のエラーだと思う" は予想
- 何が起こっているかは正確に書く、そこからの予想は間違っていてもよい
