拝啓:SRE三年生より。

これはSRE Advent Calendarの15日目です。

こんにちは。@srockstyleです。僕が関わる界隈ではすろっくさんとか呼ばれています。会社ではSite Reliability Engineeringチームに所属しています。

今の会社に入ってSREを名乗って三年になりました。振り返ると長いですね。三年前はまだSREという職種やその名前も世の中には浸透してなかったのではないでしょうか。

技術的なことや運用TIPSだったり、業務でやってる具体的ツールやフロー的なかっこいいエンジニアの話は他の人が書いたと思うんで、僕はSREとしてこんなことを感じながら仕事してるよ、みたいなエモい話をします。これからこの仕事する人や、急にやることになった人の参考になれば幸いです。

「SRE(Site Reliability Engineering)」って?

タイトルのSREってなんだよってのは割とある疑問な気がします。僕も最初「SREやって」って言われたときは「?」でした。その頃から僕自身も疑問をもっていて、自分の仕事はなにをすればいいのか、何を期待されているのか調べました。どうやらいろんな人がいうにはかつてのインフラエンジニアの担当領域+アプリケーションエンジニアの開発サポートや全体のフローの調整、全体の基盤をアプリケーションエンジニアと考えたりする仕事をするソフトウェアエンジニア……みたいなところのようです。

……ハードルたかそうですね。

魁になったGoogleがどう定義しているかはSRE サイトリライアビリティエンジニアリング って本にあるのでそちらを読んでもらうとして、とはいえ興味ない人やエンジニアじゃない人にはなにをみてもなんかわかるようなわからないような感じになってくるので、「インフラエンジニアのかっこいい名前でしょ」みたいな結論に落ち着いてしまいがちだと思います。

しばらくそんな仕事をこなす内にカンファレンスで喋る機会をいただき、2016年のPHPカンファレンスでこんなの喋りました。

途中でSREとはみたいなこと書いてますね。

いろんな会社の採用とかみてると、たまに「SRE(インフラエンジニア)」と書いてあって、どうしてももんやりしてしまいます。SREはインフラエンジニアとしての知識は最低限もっていることが前提で、そこに別なスキルが必要になるお仕事で、実際やる仕事範囲はインフラエンジニアとしての業務の範囲には収まりませんし、収まってしまってはよくないな、とは感じます。

僕も昔インフラエンジニアだったので、そう解釈してしまいがちなのはすごくよくわかります。でも今は基盤を支えるコードを書き、デプロイフロー管理のアプリケーションを作り、実際のプロダクトコードを読み、SREとしてコードレビューに参加する、など、ソフトウェアエンジニア的な仕事もあったりします。

具体的に言及してくれているのは以下の記事がためになるかと思います。僕がSREを名乗るちょっと前くらいに書かれた記事です。

やったこと

参考になるかわかりませんが、僕が今の会社に入ってやってきたことです。

  • リリースフロー の改善 (gitのフロー、ブランチの運用〜ソースコードデプロイまで)
  • デプロイ基盤の設計 / 開発 / 構築
  • ログ基盤の整備(Fluentd / Norikra などなど)
  • AWS環境のネットワーク整備(Classic環境 -> VPC環境への移行)
  • サーバのプロビジョニング&プロビジョニングツールの導入 
  • OS / ミドルウェアのアップデート作業(CentOS6 -> 7 )

新機能だとアプリケーションエンジニアと協力して、ngx_mrubyを自作のデーモンと組み合わせて独自ドメインでのSSLを実現したりしました。会社の技術ブログで詳細は書いているのでみてもらえるとうれしいです。はてぶください。

デプロイ基盤ではRuby On Rails + Octkit + AWS-SDK&hubot でgitのオペレーション、本番/ステージング/QA/開発環境など各ステージへのコードの適用をSlackから命令できるものを作りました。今でもメンテナンスをしていて、ちゃんと動いてくれています。今後はプロダクトの成長にあわせてもっといい形に変わっていくか、別なものにとって変わるでしょう。

従来のインフラエンジニア、としての役割+αの仕事をしてきた&結果をだせてきたことは先に書いたSREという存在に少しでも近づけたのかな、と思ってたりします。

やってて思ったSREはこういう存在

僕の解釈だとSREは従来インフラエンジニアが解決していた課題+αの課題を解決していくソフトウェアエンジニアなんだなと思います。

サーバとネットワークを作ってアプリケーションエンジニアに渡して使ってもらってサービス立ち上げ/あとは障害対応だけやっていた十年前のインフラエンジニアだった自分と比べるとやっている内容が増え、範囲が広くなっていて、もう当時と同じ感覚でインフラエンジニアと呼ばれると違和感を感じてしまいます。

と、まあ、僕はなんかそんなことを最近思います。

なんかえらいこといってますが他の人、他の会社では別な解釈があると思うんでマサカリなげないでください。ごめんなさい。間違ってたらごめんなさい。許してくださいすみません。

あと現役でインフラエンジニアしている人をディスってるわけでもないです。10年以上前昔のインフラエンジニアだった僕と今の自分を比べてるだけです!

立場と期待値と理解の話

そんなわけで僕はSREという慣れない職種で会社に入ったとき「この立場はこの会社にとってどんな立ち位置なんだろうか」って考え続けていました。結論としては書いた通りです。そんなお仕事ですが、やってると割と楽しいです。

とはいえSREという職種については定義づけが他の職種とくらべて非常に難しく、ちゃんと定義しているものってGoogleさんの本かメルカリさんの記事くらいで、どれが正しいかはわかりません。SREっていう立場のチームを新設することに関してはちゃんとえらいひとにどういう期待をされているのかを確認するのが大切かなと思います。

以前は僕も、SREの仕事の内に社内SEもあって人が入社するたびにPCをセットアップしたり、とあるアプリケーションエンジニアに「プロダクトのバグもなおしてほしい」とか言われて「まじか世の中のSREこんなことやってるのかパネエな」とか思ったこともありました。いまでこそ社内SEをやってくれている人がいて、アプリケーションエンジニアがやる仕事範囲も明確になってきたので、SREとは?っていうことを真剣に考えることができるようになりました。かといって自分の仕事の範囲をせばめていくとかつてのインフラエンジニアにおちついてしまうので、そうならないようにしていきたいですね。

まとめ

緊張することも多く、やっててすごく疲れる仕事ではありますが、人によってはやりがいがある仕事だとは思います。

ためになったかわからないですけど、こういうこと考えながら仕事してるSREもいるんだな、と思ってもらえれば幸いです。インフラの知識を持ちつつ、ソフトウェアエンジニアとして攻めの運用をするのがSREという存在です。僕もまだ道途中ですが、頑張っていきたいと思います。全てのSREが楽しく仕事できますように!。

割と人手不足感ある職業なので、興味あったら転職してみたらいいと思います!

次は16日目ですね。@tshohe1 さんが書かれるようです。よろしくです!

in SRE | 79 Words