おことわり

あくまで感想を文章として一度書いてみたという投稿ですので役に立つプラクティスとかは書いていません。

なにやってるの

大まかには以下のようなことを最近はしています * パフォーマンスチューニング * モニタリング * インフラ構成見直し * CI環境整備 * 開発環境整備 * 日々の運用のお手伝い

アプリケーションに関してはドメインの知識が豊富な各チームのメンバーに、インフラに関してはインフラチームに相談しつつ進めることになるので、結果としてチームとチームの橋渡し的な感じのことをやることもあります。

少し前のLTですが概要はそんなに今も変わってません。

ポジション的にはこちらの投稿の一番下の図のような感じです。 https://qiita.com/san-tak/items/1e8a6aae062c5f6c4c64

最初に提唱されたSREとやっていることがかぶる部分もあれば、違う部分もありプラクティスについても実践していることや、実践しないという選択を行ったものもあり、そういったところについても今回とはまた別の機会に触れたいという話はあります。

サービス全体の改修をする裁量を与えられているので楽しいし成長にもつながる。

一方でサービスのいたるところで起こる問題についてジャッジを下すことが必要なので立て込むと大変。

現在は、インフラとアプリケーションの両サイドに働きかけられるポジションで仕事をしているため、大きな問題を分解した時にインフラ側とアプリケーション側、それぞれから攻めることができます。

例えばパフォーマンスチューニングに関してはアプリケーションコードのチューニングだけでなくそもそものパフォーマンスの計測方法や止む無くインスタンスタイプの変更(金の弾丸)なども検討します。

パフォーマンス劣化など一つの問題を起点にして、サービスを取り巻く仕組みなども含めて広く検討できるため技術的な(あるいは技術以外も含めた)引き出しが1年前に比べて大きく広がったと感じます。(特にAWSのサービス全般)

一方でシステム全体を見ることができる分問題が集中してSREの手が回りきらない時もあり、低コストでインパクトが大きい改善活動が求められているとも感じています(できているとは言っていない)

本当は監視の改善や自動化、ライブラリの改修などに専念したいが実際には単純にサービス運用年数が経過するだけでも対処が必要な問題が起こり、過去の負債がシステムの成長を妨げることもありままならなかったりして難しい。

そして日々の運用業務に対処するだけでも工数負荷がスパイクすると首が回らなくなることもありSREチームの工数がシステム運用のSPOFになることもあり申し訳無さが高まる時期もある。

上記のように、今SREチームが工数足りていないという話もあり、SRE以外もSREみたいなことやっていけるような会社になるといいなあ、と思ってまずは下記のようなところからやっていきたい気持ちがあります。

こんな感じのことをやって半年後とか一年後にまたブログとかLTでご報告できたら嬉しいなあ、という気持ちでやっていきます。他社で似たようなお仕事されてる方がどういう気持ちでお仕事されてるのかとか興味あるのでそういうブログとか発表とかお待ちしております。