ITエンジニア(くそデカ主語)なら絶対に理解しておくべき作業フロー

つい先日信じがたいことをプロから聞いたので、
技術情報として役に立たなくなったQiitaに
久々にログインして書きなぐろうと思います

発端

??? < 手順書.txt(中身はコマンドの羅列だけ)を
渡されてドン引きしてる

??? < 事前と事後の確認くらいはしような
(ガチ設定用のコマンドしか書かれてなくて世紀末)

というお話を聞いたのでこれから無能を増やさないように
オワコンプラットフォームに便所の落書きとして残します

というかこういうのはSIerに入ったら教えてもらうことなんじゃないのか…？
自分の場合は派遣会社だから一度も教わったことないけど

結論

先に結論書いときます
手順書やスクリプトはこれを想定して作れ

作れないんなら自分の責任で作業時に常駐して直せるようにしろ
クリティカル作業の場合はそういうことを
絶対にやるな カス

事前作業(変更前の想定した状態や設定かを確認)
変更作業(やりたかったこと、顧客が本当に求めていたもの)
事後作業(変更後の想定した状態や設定になったかを確認)
切り戻し作業(ロールバックしたり元の状態に戻すコマンドなりを使う)

なんで事前作業が必要なの？

少しは考えろ
疲れた頭や酒をキメたりした状態で前回の作業でやっていたり、
他人が設定変更をしていたりしたら想定通りの状態になるわけないだろ

なんで変更作業が必要なの？

これは言う必要はないはずだが、わからないなら何しに来たんだ

なんで事後作業が必要なの？

自称神でさえ欠陥品の人間しか作れないくそ雑魚なんだから
人間が完璧に間違えないことなんてないだろ
46億回 考えて 確認してろ

すべてが想定通りなんて甘いんだよ

なんで切り戻し作業が必要なの？

事後作業と同じ理由
あとは予期しないバグを引いたりしたら
元に戻せないと死ぬ

ほかに気を付けるべきことは？

本番と

全く同じ

検証環境を作れ
作れないなら客を殴り倒して作らせろ
それでも首を縦に振らないなら瑕疵を担保すんな

妥協ラインを明確にして契約書にかけ

そうはいっても予算がないから無理といわれるが

本当は求めていない作業なんじゃないかとしか思えないが、
クリティカルなものじゃないから妥協して下記のような
検証環境を提案して費用だしてもらえばいいんじゃねーの
知らんけど

ただ、クリティカルなはずなのにケチるような客は二度と関わるな
即撤退しろ
諸悪の根源だ

IPアドレスが重複しないように隔離して、同じホスト名やIPアドレスを使って作る
下位互換や中古機器でほぼ同じ設定や機能があるものを買って対応する
仮想マシンで作れるものはつくる(ベンダーロックインの必要がなければネットワーク機器も仮想でできなくはない)

なんもわからんので例をくれ

あなたが働いてる会社大丈夫ですか？

Cisco

IOS-XRとかまともなやつはロールバック機能があるのでこんな切り戻ししなくていい
というか標準でつけろ

事前作業

ter le 0
sh clock
sh run
sh startup-config
sh int status
sh int bri

変更作業

conf t
int Gi 1/0/1
no shut
end
wr mem

事後作業

sh clock
sh run
sh startup-config
sh int status
sh int bri

切り戻し作業

conf t
int Gi 1/0/1
shut
end
wr mem

Linux

VMならVMのスナップショット使えばいいし、
NILFS2やHammer2などを使ってればファイルシステムのスナップショットを使えばいい
あとは/etcの設定を変えるだけならetckeeperいれるといい
これらがあると切り戻しが楽になる

大した選定基準もないのに実機を使ったり、
xfsやext4が人気だからって理由でスナップショット機能がない
ファイルシステムを使うのはやめろ

事前作業

uname -an
date
ls -l /var/log
cat /etc/rsyslog.conf
sudo systemctl status -l rsyslog
sudo journalctl -xe -u rsyslog

変更作業

sudo systemctl enable rsyslog
sudo systemctl restart rsyslog

事後作業

uname -an
date
ls -l /var/log
cat /etc/rsyslog.conf
sudo systemctl status -l rsyslog
sudo journalctl -xe -u rsyslog

切り戻し作業

sudo systemctl stop rsyslog
sudo systemctl disable rsyslog

切り戻しがあった場合はどういう手順になるの？

想定できないならエンジニア向いてないと思う

事前
変更
トラブル発生
切り戻し
事後(事前と同じ設定や状態になる)

になるだろ
この切り戻し手順と下記の通常手順は検証で絶対に確認しろ

事前
変更
事後

ちょっとだけ眺めたサイト

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/s1-basic_configuration_of_rsyslog
http://itdoc.hitachi.co.jp/manuals/3021/3021373110/0015.HTM
https://techracho.bpsinc.jp/yamasita-taisuke/2014_08_14/18762
http://www.tensi.info/home/kensyo-infra
https://it-trend.jp/development_tools/article/32-0033

最後に・ファッキンお気持ち

勢いで書いてしまったのですごく内容が汚くてつらい
でも反省はしていない

こういう基本的なことを書いている資料や書籍をまだ見たことがないので
理解に苦しんでいるが、俺がアホなだけで見つけていないだけな気がするので
もしまともな書籍にこういうことがかかれていたら教えてほしい

あと、修正とかはやる気や気が向いた時や余裕があるときに運が良ければやる