はじめまして。このブログの管理人のまきぞうです。
「2 ヶ月間かけてやっと作り終わった機能のリリース後、サービスがダウンして使えなくなってしまった。」
そんな経験ありませんか？
身に覚えのない機能だと思って原因を調べていくと、だんだんと見覚えのあるコードに辿り着いていくにつれザワザワしてくる感じ。
自分が書いたコードが、あるいは自分が見たこともないインフラのどこかが原因でサービスが止まっているかもしれないというプレッシャー。
何を隠そう、これは数年前まで Web アプリケーション開発者として働いていた僕の日常でした。
もし、あなたも同じような経験をしたことがあるなら、このブログはきっとあなたのためのものです。
この最初の記事では、機能開発こそがエンジニアの華だと思っていた僕がどのようにして SRE（Site Reliability Engineering）という一見地味に見える世界に深く魅了されていったのか、その旅路をお話ししたいと思います。
「作って終わり」の先にある見えない壁
僕はもともと、ユーザーのための新機能を考えコードを書き、それがリリースされて世界に使われることに何よりのやりがいを感じるタイプのエンジニアでした。
試行錯誤しながら、「こうしたらどうだろう？」と考えて作った機能がお客さんに使われている時はとても楽しかった。
当時の僕にとって、「運用」や「インフラ」はどこか遠い世界の話でした。自分が作ったアプリケーションが動く「土台」。
正直に言えば、「作ったものはあとはよろしく」という気持ちがなかったわけではありません。
しかし、サービスが成長するにつれてその「土台」が静かに悲鳴を上げ始めます。
- リリース直後に発生する原因不明のパフォーマンス低下。
- 深夜にだけ発生し朝には収まっている謎のアラート。
開発チームとインフラチームの間には、見えないけれど分厚い壁がありました。
価値観を揺るがした「Kubernetes」という名の宇宙
転機は、技術的な好奇心から訪れました。
ある日上司との雑談で、「Kubernetes」という単語が頭に入ってきました。
「kubernetes がコンテナオーケストレーションのデファクトスタンダードだ」と言われても、当時の僕には Docker コンテナを少し触ったことがある程度の知識しかなく、正直ピンときていませんでした。
「コンテナって開発環境のためのものじゃないの？なんだか面白そう！」そんな思いから、僕はプライベートな時間を使って個人的な Web アプリを Kubernetes 上で動かしてみることにしました。
最初は悪戦苦闘の連続でした。無数の YAML ファイル、Pod、Service、Deployment…。
「ただアプリを動かしたいだけなのに、なぜこんなに覚えることが多いんだ！」と何度も心が折れそうになりました。
しかし、基本的なお作法を理解し、初めて自作アプリが Pod として起動し Service 経由で外部からアクセスできた瞬間、僕は気づきました。
これは、単にコンテナを動かすためのツールではない。これは「信頼性の高いシステムを構築するための思想そのもの」なのだと。
特に僕が衝撃を受けたのは、**自己修復（Self-healing）と宣言的（Declarative）**という 2 つの概念です。
アプリケーションのプロセスがエラーで落ちても、Kubernetes が自動で新しい Pod を立ち上げてくれる。
デプロイに失敗しても、コマンド一つで以前の安定したバージョンに瞬時に戻せる。
これは魔法のように見えました。深夜にアラートで叩き起こされ、手作業でサーバーを再起動していた僕の悩みは Kubernetes の世界では「仕組み」によって自動的に解決されるのです。
「どうあってほしいか（宣言）」を YAML に書けば、Kubernetes がその状態を維持し続けてくれる。
これは、リリース作業を「一発勝負の怖いイベント」から「いつでも安全に実行できるルーチンワーク」へと変えてくれる、強力なパラダイムシフトでした。
SRE は「守り」じゃない、「攻め」のエンジニアリングだ
Kubernetes という「具体的な How」に魅了された僕は、その背景にある「Why」。
つまり設計思想に興味を持つようになりました。そしてその探求の先にあったのが SRE でした。
Kubernetes が提供してくれる自己修復、宣言的な状態管理、スケーラビリティといった機能はまさに SRE が目指す「ソフトウェアエンジニアリングによる、運用の問題解決」を具現化したものでした。
- システムの状態をコードで管理する「Infrastructure as Code」
- 退屈な手作業（Toil）を徹底的に自動化する「自動化」の思想。
- システム内部で何が起きているかを詳細に可視化し、未来を予測しようとする「オブザーバビリティ（可観測性）」の探求。
どれもこれも、僕が開発者として大切にしてきた「良いソフトウェアを作りたい」という思いと深く結びついていました。
SRE は障害を防ぐだけの「守り」の役割ではありません。
それは、信頼性という最高の機能を提供するためにソフトウェアエンジニアリングの力で問題を解決していく極めて創造的で「攻め」のエンジニアリングだったのです。
このブログで目指すこと
このブログでは、かつての僕と同じように、
- サービスの信頼性という新たな責任に直面した戸惑っている
- SRE や Kubernetes に興味を持ち始めた
という Web アプリケーション開発者のあなたに向けて、僕が学んできたことを共有していきたいと思っています。
目指すのは 「開発者のための、実践的 SRE」 です。
SRE の分厚い教科書を要約するのではなく、経験や書籍から噛み砕いてあなたの日常業務に明日から活かせるような、具体的で実践的な知識や Tips に焦点を当てていきます。
- Kubernetes 上で動かす Web アプリの最適な Dockerfile の書き方とは？
- 開発者が知っておくべき最低限の監視設計とは？
- 初めてのオンコール当番をどうすれば乗り切れる？
そんなあなたの「知りたい」に、開発者としての視点から応えていきたいです。
もしあなたが、機能開発のその先にあるサービスを支える技術に興味を持ち始めたなら。
もしあなたが、深夜のアラートに怯える日々から自信を持ってサービスを成長させる日々に変えたいと願うなら。
これから、一緒に学んでいきましょう。 あなたのエンジニア人生が、もっと楽しくもっと刺激的なものになる。その一助となれたらこれほど嬉しいことはありません。
最後まで読んでいただき、ありがとうございました。