趣味の延長でも手順は必要
筆者はサーバ運用の、ほぼすべてを手順化しています。
「なぜ、趣味の一環なのにプロのような手順を設けているのか」を疑問に持った方もいるでしょう。
これに関しての理由付けを示します。
「未来の自分が慌てないため」
これに尽きます。私の性格上、一度躓いた作業は二度目以降も同じところで詰まります。
「この私なら絶対にやらかす」
という、自分の信頼のなさへの信頼感があるため、
- 注意すべきポイント
- 何を持って「完了」とするのか
- “やらかした”場合のリカバリ方法は?
などのPoint of No Return (回帰不能点)を少しでも減らすための強力なアンカーとしてマニュアルを作成しています。
特に、障害というやつは「起きてほしくないタイミングで起きる」から障害なのですから。
歴史的意義。
そもそも「マニュアル(Manual)」とは、ラテン語の「manus(手)」という単語に由来しています。
元々は「手を使う」「主導の」と言った意味の形容詞でしたが、そこから派生して「手引き」や「取扱説明書」といった名詞の意味で使われるようになりました。
- management
- manufacture
- manicure
なども、すべて同じ語源から来ており、「手」に関する言葉となっています。
古代ローマと「マニュアル」
古代ローマ軍が規格外の強さを誇った背景には、「行動が全てであり、一定の標準的機能の遂行が勝敗を決定する」という思想があったとされています。
- 古代ローマ軍の強さは、厳格な軍規と徹底した訓練によって支えられていました。
- 膨大な数の兵士と多岐にわたる任務を効率的かつ確実に遂行するためには、経験や感覚に頼るのではなく、手順や規範を統一し、共有することが不可欠でした。
- この技術や行動の「言語化・共有化」は、現代でいう標準化やマニュアル化の考え方につながるものであり、古代ローマの軍事的な成功の重要な源泉の一つであったと言えます。
特に、古代ローマ軍の圧倒的な強さは「各人が優れた土木技術者であり、野営のみならず街を作ることすら可能だった」ことにも現れています。
各軍人が軍事技術だけではなく土木技術の手引き書も共有化されていたからでした。
つまり
マニュアル通りとは、漫画や小説で言う
- 融通が利かない人
- 堅物
という意味ではないと筆者は考えます。むしろ「想定外の出来事が起きたとしても標準以上の行動ができるための引き出し」として定義しています。
マニュアルを作る意義
技術の言語化
- どの要素を組み込んだから上手くいったのか
- 何が元で失敗したのか
- これを「同じ轍を踏まないようにするためには?」
など、すべての人が生み出した技術は言語化される余地があります。この言語化というやつは「自分の意を伝える」「相手の意をくみ取る」の両方で必要であり、他者からのフィードバックをもらうための最高の機会となります。
詰まったところの確認
失敗した部分のロギングです。
「マニュアルのどこが行けなかったのか?」を確認することで、すっ飛ばしたところや、怠った事による裏目がすべて結果となって現れます。
では、具体的なものを。
以下、筆者が過去に行った「Ubuntuサーバにスワップを設定する」手順です。ここで、実際にどのような点に気をつけてマニュアルを作っていったかを解説します。
### 環境
- Ubuntu 24.04
- 4GBメモリ/80GBディスクのインスタンスを利用
### さっくりとした手順
1. 現在のメモリとディスク容量を確認します。
1. Swap領域を確保します。
1. 確保したSwap領域を有効化します。
1. Swap領域が増えたことを確認します。
1. fstabを修正します。
1. fstab修正後にシステムを再起動し、Swap領域有効化を確認します。
- ここで環境を定義するのは「スタート地点が明確でないと明後日の方向に行ってしまうから」です。既に設定されている場合は作業をする必要が無いという目安になります。
- さっくりとした手順を記すのも、「だいたいの時間の見積もり(Estimated Time of Arrival)」を取るためです。これにより、いつ行うべきか、どのぐらいの工数を取るべきかの目安となります。
#### 作業の前に
ディスク起動時のオプションなど、特に重要なシステム領域の設定ファイルを修正する作業です。
失敗時に復旧できるようシステム全体のバックアップを取ることを強く推奨します。
これは、先に挙げたPoint of No Return (回帰不能点)を「Point of Returnable (回帰可能点) 」とするためのおまじないです。最悪の事態を挙げておくことで、もしもの時に備えます。
#### 現在のメモリ情報を確認
- メモリ情報を確認
free -h
-hオプションは(human readable)の略だそうです
- 実行結果
total used free shared buff/cache available
Mem: 3.8Gi 450Mi 2.9Gi 2.5Mi 688Mi 3.4Gi
Swap: 0B 0B 0B
Swapが全く作成されていません。
#### 現在のディスク容量の確認
- 要領確認
df -h
- ○実行結果
Filesystem Size Used Avail Use% Mounted on
/dev/root 78G 5.0G 73G 7% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 784M 980K 783M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/vda15 105M 6.1M 99M 6% /boot/efi
tmpfs 392M 12K 392M 1% /run/user/1001
容量は問題ありません。実メモリと同じ4GBの領域を作ります。
と、作業の前の確認を行います。Markdownの判定で省いていますが、
1コマンド1ブロック というルールを遵守するように筆者は心がけています。
それがたとえ、参照するための
free -h
であってもです。この、最初の一歩を確認できない場合は
sudo rm -rf ./*
などの重要で致命的なコマンドも疎かにしてしまうからです。
#### Swap領域の確保
- Swap領域作成
sudo fallocate -l 4G /swap
- ファイル作成確認
ls -ldh /swap
指定ディレクトリに4GBのファイルがあることを確認します。
#### Swapの有効化
- /swapのパーミッション変更
sudo chmod 600 /swap
- パーミッション変更確認
ls -ldh /swap
rootのみが読み書き可能なことを確認します\
#### /swapの設定
- Swap領域作成
sudo mkswap /swap
- 実行結果
スワップ空間バージョン 1 を設定します。サイズ = 4 GiB (4294963200 バイト)
ラベルはありません, UUID=08cf06da-757e-4ab4-b049-e7da8ee73341
★/swapの有効化
sudo swapon /swap
#### Swap有効化確認
- メモリ情報確認
free -h
- ○実行結果
total used free shared buff/cache available
Mem: 3.8Gi 446Mi 2.9Gi 2.5Mi 689Mi 3.4Gi
Swap: 4.0Gi 0B 4.0Gi
4GBのSwap領域が確保されました。
ここで、作業手順を一気に書きます。ここでも、一つ一つの確認を行うことで、「すっ飛ばしたときのリカバリー」を容易にしています。
#### fstab設定
- /etc/fstabのバックアップ
sudo cp -pi /etc/fstab /path/to/backup/directory/fstab.$(date +%Y%m%d)
- バックアップ作成確認
diff -u /path/to/backup/directory/fstab.$(date +%Y%m%d) /etc/fstab
差分が無いことでバックアップが取れていることを確認します。
- /etc/fstab追記
cat <<- __EOF__ | sudo tee -a /etc/fstab
/swap none swap sw 0 0
__EOF__
- 差分確認
diff -u /path/to/backup/directory/fstab.$(date +%Y%m%d) /etc/fstab
- 差分
+/swap none swap sw 0 0
ここでは、「単にスワップを作成しただけでは終わらない」というLinuxのファイルシステムに言及しています。この/etc/fstabはディスク全体を司るテキスト群。そのため、
- バックアップ
- 実施時のオペレーションを確実に減らすための
teeによる追記 - 追記後のdiffによる確認
と、「実際に作業を行ったか」を感覚では無くコマンドという冷静で絶対的な眼として確認します。
#### 再起動後の修正確認
- システム再起動
sudo reboot
- 再起動後の確認
以下が確認できれば作業完了です。
1. サーバにログインできること
1. Webサービスなど既存システムが設定前と同様に稼働すること
1. free -h を実行し、Swap領域が確保されていること
ここで、最終確認を行います。rebootを実施するのは、それだけシステム全体に関わる作業を行うからです。
ここまでやって
ようやく筆者の「標準」といえる手順書が作成されました。まぁ、最初にここまでやるというのは酷な話ではあると思いますが
- まずは非常に簡単な手順書を作る。それこそ
systemctl status apache2.service→sudo systemctl restart apache2.service程度で構いません。 - そこから一つずつ発展させていく
と、ある程度の段階を積んでいくことが、より確実な手順と言えます。
最後にもう一つ
「自分で作った手順書が有効かどうか、第三者に実際に行ってもらう」手法は極めて有効です。
その手順書で失敗してしまったら → 確実に作成した自分自身の責任です。
この、言語化・共有化というのは「間違った手段も共有される可能性がある」からです。私もそうならないよう気をつけますが、
『超電磁マシーン ボルテスV』の
岡長官
「そんな杓子定規な」
左近寺博士
「杓子結構、定規賛成」
という、割とガチめの引用で以て本稿を締めくくります。