Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2022年10月26日にMarco Bulgariniが投稿したブログ（https://sysdig.com/blog/should-you-trust-tools/）を元に日本語に翻訳・再構成した内容となっております。
私の父は、イタリアに輸入された初期のコンピュータをいくつか使って仕事をしていました。技術者といえば、現場での経験、分厚い技術マニュアルの束、そしてフル装備の道具箱の3本柱で成り立っていた時代です。マニュアルがない、交換部品がない、となると、お客様先から本社まで1日がかりの出張になることも珍しくありませんでした。
現在、状況は大きく変わっているように見えますが、実はそれほど大きくは変わっていません。技術マニュアルは埋め込まれていることが多く、インターネットという小さなものでどんな質問にも答えてくれます。それでも経験は決して代え難いものであり、私がこの記事を書いている理由はまさにこの「道具箱」にあります。
さて、ここで父の道具箱の話に戻ります。私は今でも、父が使っていた道具一式の一部と、ごく普通のドライバーをいくつか持っています。しかし、硬いネジを扱うたびに、新型のマグネットチップやラバーグリップを手放し、昔ながらのシンプルな道具に戻っている自分に気づきます。
一日中インフラをいじっていると、数年前までは父のような道具箱だったのが、今ではソフトウェアエンジニアのようになっています。私は日常的にプログラムを追加したり削除したりしていますが、今日までその選択の意味をあまり深く考えていませんでした。
“信じてください、私はエンジニアです” - 午後の間に本番環境を2度壊した方法
Lens の登場です。数十の Kubernetes クラスターを管理するために Lens を使っています。リソースのステータスを素早く確認し、関連リソースにすぐ移動できる点が気に入っています。
ある日、Pod がデータを処理していないという通知を受け取りました。ログを見ると Full GC で停止中。Pod 名を確認し “Delete” をクリック。すると、削除されたのは Pod ではなくデプロイ全体でした。
災害。
--cascade=orphan
であることを祈りましたが、すべての Pod が消えました。
"おいおい、バックアップが必要だ、俺はしくじったんだ。"
数人の同僚の助けでパイプラインを再起動し、失われたマニフェストを再デプロイ。Slack でインシデント報告を共有し、恥ずかしさに耐えながら詳細を説明しました。
その後、Kafka の StatefulSet でも同様のことが起こりました。再び “Delete” を押すと、今度は StatefulSet 全体が削除されました。
"おい、まだオンラインなの？ 今度は Kafka で再び起こりました。"
数分後に復旧しましたが、なぜ同じミスを二度もしたのか自問しました。調べてみると、この挙動は Lens の既知のバグでした。
https://github.com/lensapp/lens/issues/5492
私はインシデントチャンネルでアラートを発し、他のユーザーにも注意喚起を行いました。
反省 / 振り返り
何が起こったのか、本番環境で Lens を使用することの正当性について考えました。使うべきではなかったのか？承認が必要だったのか？どのような基準でツールを信頼すべきか？
基本に忠実であること
最も単純な答えは「物事を複雑にしすぎず、基本的なツールにこだわる」ことです。しかしこのアプローチにも問題があります。
1. "基本" の定義は何か？（複雑さ）
kubectl
は必要悪であり、
Lens
や
k9s
などのダッシュボードは本当に過度なのか？ クラスタ数が増えると、これらを使わないのは非現実的です。
2. 生産性（時間）
速く動ける一方で、ツールボックスのどれだけを犠牲にできるでしょうか？追加された複雑さと価値のバランスを取るのは難しい。特にインシデント対応では、迅速な復旧のために賢いツールが必要です。
3. "基本的なこと" にもリスクがある
古いツールにもリスクがあります。数ヶ月前、バニラの kubectl でも同様の問題がありました。それでも誰も SSH や Telnet に戻ることはありませんでした。
DIY
「何も信用せず、すべてを自分でビルドする」方法もありますが、多くの場合コストが大きく、リスクも伴います。
kubectl
や
openssl
を自作する必要はありません。テンプレートエンジンは
gotemplate
より優れていません。
より良いアプローチ
私が再発防止を考えるなら次のようにします。
道具箱は標準化するが、選択肢は残す
標準ツールの完全遵守を強制するのではなく、チーム全体で共有ツールを使い、バージョン管理を統一します。たとえば:
共有ツールボックスを中心にコラボレーション文化を築き、オーナーシップとエバンジェリズムを奨励します。
信頼、しかし検証
ツールを採用する前に、最低限の審査を行うべきです。基準の例:
- 活発なコミュニティがあるか。
- リリース頻度と修正スピード。
- ソフトウェアサプライチェーンの透明性（署名付きバイナリ、SBOMの有無）。
FOSSを書く
社内ツールが必要なら、最初からオープンソース化を視野に入れましょう。利点:
- より良いコードを書くよう促される。
- 自動化が透明になる。
- メンテナンスがコミュニティと共有される。
エンジニアに勤務時間中の OSS 活動を認めるのは自然な投資であり、企業にとっても健全です。
次にくるものは？（失敗を受け入れることについて）
不快な経験でしたが、ツールが生産性だけでなく安全性と回復力にどう影響するかを理解できました。
1. ツーリングの必要性を減らす（弾力性を優先）
手動介入が不要な設計にすべきです。健全でない Pod は自動回復し、ノード障害は自動的に代替されるようにすることが理想です。
2. カオステストの導入
障害が起きても影響を受けないように、カオス実験を実施します。