なんだかんだでLinuxの業務経験が1年半になったので今までにやらかした~~(死にかけた)~~経験を書いていきます。
特に最近はオンプレだとBIOSレベルで操作できてたのが、クラウドだとできず詰みかけるパターンも多いです。（救えるパターンもあり）
やらかし防止と、リカバリ含め傷を最小限に抑えられればと思います。
※本記事はRHEL7,CentOS7を前提とします。
ざっくりと筆者の経歴
- 高専時代：Linuxによる自宅サーバ運用歴2年(何も理解してなかった)
- 最近：Linux業務経験1年半
- LPICレベル1所持
- 応用情報技術者
- 業務歴は6年くらい(Linuxやる前は、Windows,Networkが中心でした)
SElinuxの編集ミスで死亡
SElinuxの無効化を行うために、コンフィグファイル(/etc/selinux/config)を修正。
本来は「SELINUX=disabled」とすべき所を、
誤って「SELINUXTYPE=disabled」としてしまった。
またはタイプミスなど。
詳細はこちらで紹介されてるので割愛。
https://qiita.com/daisuke0115/items/4b0ed3a5888cf81efd0a
biosレベルでマシンに接続できる環境なら良いですが、AWSなどのクラウドだと詰みかけます。
→別EC2に該当のEBSをマウントして編集で救えます。
http://blog.serverworks.co.jp/tech/2020/04/14/post-82871/
ただし、国産クラウドみたいに？ディスクの付け替えが容易に行えない場合は詰みます。
バックアップから戻す、もしくは再構築が必要になります。
対策
こればかりはコピペで行って、更にとかやると安心。
cat /etc/selinux/config | grep SELINUX=disabled
fstabの編集ミスで死亡
正しい例
/dev/sda3 /home xfs defaults,nofail 0 2
自分の場合は途中のxfsを書き忘れて再起動し、ssh接続不可に。。
これもやってしまった場合、上述と同じ方法で救えます。
が自分が触ってたクラウド環境はそれが使えず、バックアップから復元しました。
対策
sudo mount -a
でエラーが無いことを確認してから再起動を行う。
俺は構築の勢いでそのエラーを無視して再起動してしまったんだ。。ﾕﾙｼﾃ
余談
クラウドサーバーの追加ディスクマウント時はnofailオプションを！
https://inaba-serverdesign.jp/blog/20170210/cloud_disk_mount_fstab_nofail.html
にあるようにnofailをつけましょう。
root sshの許可で死亡
(編集ミスとはまた少し違う気もしますが)
原則サーバに置いて、rootのsshは無効です。
稀に閉域環境下では便器性などで一時的に有効化されているケースもあります。
自分の場合はついそれに慣れてしまい、検証として立てて頂いた、公開サーバでも変更してしまいました...
→クラウドサービス（Azure）のアタック検知により発覚し変更。パスワードは複雑なので事なきを得た。
※AWSは公開鍵認証固定ですが、AzureはSSH公開鍵認証と文字列認証が選べるようです。
対策
- 操作するサーバが誰がアクセスできる状態か認識する。
- 社内ネットワークのみなのか
- 情報を知っていればどこでもアクセスできるのか
- 公開サーバで文字列認証は極力使用しない。使用する場合はユーザ名を複雑にする。
- 公開サーバとはいえ可能であればセキュリティグループでSSHは接続元を絞る。
番外編：AWSのEC2誤削除
検証サーバをさー停止するかってと思って操作してたら終了を選択していた。
terminated と表示される画面と、真っ青になる俺
対策
終了保護を有効にしましょう。
あとはAMI、スナップショットの取得、場合によってはIAMレベルでの制御を行いましょう。
今回は何もしてなかったので3時間くらいかけ構築し直しました。。検証用サーバとはいえ痛い。
フェールセーフと言う考え方
今回の失敗を受け改めて意識しました。
フェイルセーフ（フェールセーフ、フェイルセイフ、英語: fail safe）とは、なんらかの装置・システムにおいて、誤操作・誤動作による障害が発生した場合、常に安全に制御すること。 またはそうなるような設計手法で信頼性設計のひとつ。 これは装置やシステムが『必ず故障する』ということを前提にしたものである。
https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A7%E3%82%A4%E3%83%AB%E3%82%BB%E3%83%BC%E3%83%95
情報処理の試験でよく出ますが、システムを設計する上では必要な考え方です。
そのままフェールセーフの考え方を取り込む。というよりは「人間は必ず失敗する」ので、失敗を前提に作業する。という意識が大事です。
(細かく言うと対策によっては別の信頼性設計だったりしますが割愛)
今回のケースだと、以下を考えましょう。
- 誤操作を仕組み的に減らす
- 再起動後適応等の場合は、記載したようにチェックを入れる。
- 本番作業は開発・ステージング環境で実績のある作業手順を使う、オペレーター、チェッカーの2名体制で行う。
- 手動でConfigを編集せずに、Ansibleなどの構成管理ツールを使う。
- 誤操作が起きてもバックアップなどにより元の状態に復元できるようにする。
- Configを編集するときはシステムバックアップを取得する。
- システムバックアップに加え、業務データなどを別途バックアップする。
- 誤操作が発生しても、業務影響を最小限に抑える。
- 本番作業の場合は、サービス時間外に作業を行う。
- (操作に対するリスクを理解すること)←フェールセーフとは違いますが大事であり、これが一番経験が物を言ったり...
日常生活にも応用ができて、いい例が出ないですが...
- 雨が降ってもいいように折りたたみ傘をいつも持ち歩く
- 自分はリップクリーム必須なので、職場、鞄など使う場所に置いておく。
- 当日の朝は理想の時間に起きれない可能性があるから、前日のうちに荷物を準備する。
- お米を炊いたあと冷凍を忘れないように、手間だけど後回しにせず食事前に必ず済ませるとか。
クラウドサービスは気軽に起動停止できる分、コンソールから(BIOSレベル)の作業ができずトラブル時逆に面倒なときもあります。
失敗例や、オペレーション時のリスク想像とかにより、製造業で言うヒヤリハットのように防げるミスは事前に防いで行きましょう。
本番環境でやらかしちゃった人 Advent Calendar 2019
https://qiita.com/advent-calendar/2019/yarakashi-production