エンジニアにLinuxが必要な理由

「自分のパソコンでは動きました」が通らない場所

書いたコードは、最後には自分の手元を離れます。リポジトリに push され、CI で自動テストされ、コンテナイメージに焼かれ、本番サーバーで動きます。この経路の途中から先は、ほぼすべて Linux です。手元が Mac でも Windows でも、コードが着地する場所は Linux だと考えて構いません。

だから、動かなかったときに調べる場所も Linux です。ここが読めないと、原因の切り分けが「もう一度デプロイしてみる」しか残らなくなります。

障害の朝、最初の 5 分に何ができるか

サービスが止まっているという連絡が朝に入ったとします。Linux が使えるエンジニアの動きは、だいたい次のような形になります。

サーバーに入り、サービスの状態を確かめ、直前のログを 200 行読む。ここまでで、落ちているのはアプリ自身なのか、その手前のネットワークなのか、ディスクが埋まっただけなのかが大きく絞り込めます。この 3 行を打てるかどうかで、復旧までの時間が変わります。

逆に、ダッシュボードの赤いグラフを眺めるだけでは、どれだけ待っても原因は出てきません。グラフは何かが起きたことを教えてくれますが、何が起きたかはサーバーの中にしかありません。

コンテナを作るのは、小さな Linux を組み立てること

「クラウドだから OS は意識しなくていい」と言われますが、実際は逆です。Docker を使うということは、自分で OS の中身を選ぶということです。

4 行のうち 3 行が Linux の話です。どのディストリビューションを土台にするか、パッケージをどう入れるか、実行ファイルを /usr/local/bin に置くのはなぜか。Linux の感覚が無いと、この 4 行はどこかから写してきたおまじないになり、軽くも安全にもできません。

解説

言語やフレームワークは数年で入れ替わりますが、ls や cd の使い方は 30 年ほとんど変わっていません。ここに使った時間は、いちばん長持ちする形で残ります。