現在、データベースをクラウドで提供する会社の Site Reliability Engineer (SRE) として働いています。
文系出身でモバイルエンジニア出身な私ですが、色々と周り巡って今の職種に行き着きました。SRE というのは Software Engineer の間でもすっかり定着しているので、わざわざ「SRE とは何か」から説明しなくても通じると思います。日本のスタートアップでも、SRE を採用しているケースや SRE チームを立ち上げているケースも多いことでしょう。
ご存知の通り SRE という言葉は Google が提唱・定義したわけですが、あれは狭義としての SRE だと思っていて、正直、実態としての "SRE" の職務領域は会社によってまちまちだと思っています。この記事では、後者を広義の意味での SRE と仮に定義しておくこととしましょう。
狭義の意味での SRE は、Reliability Engineering、アプリケーションの信頼性を向上するための一連の手法だと理解しています。信頼性を向上させるためのアプローチとしては、監視・アラートの設定や Software Engineering (SWE) といった技術要素からのアプローチのみならず、設計・デザインフェーズからのアプローチ、SWE チームとの関係性やビジネス側との交渉・折衝からのアプローチ、障害対応の一連のフロー構築からのアプローチなど、あらゆる手法を駆使してとにかく「信頼性を上げる」ことに重きを置く職業です。
広義の意味での SRE は、ざっくり「SWE 以外の領域ほぼ全て」に責務を担っているケースもあります。開発者環境の構築であったり、セキュリティ対策であったり、データセンターやクラスターの管理であったり。もちろん、これらの領域を別の職種として "DevOps Engineer", "Security Engineer", "Platform Engineer" と分けている会社はありますが、例えば Seeds ~ Series A/B あたりの会社では、SRE として公募していながら、実態としては DevOps Engineer だった、というケースも耳にします。また、SRE チームで働いていても、他のチームからは「とりあえず技術が分からなかったら何か知ってそうなチーム」として見られることもあります。
また、SRE と似て非なるものとしては "Production Engineer" という言葉も耳にするようになりました。Meta や Shopify がその例です。それらのチームで働いたことはないので実際どこまで違うのかはわかりませんが、プロダクションで稼働するアプリケーションを安定稼働する、という点は「信頼性」と言い換えられるケースが多いので、実際ほぼ同じなのでしょうか（詳しい方いたら教えてください）。したがって、SRE として働いていると Production Engineer としてリクルーターからアプローチされるケースも増えてきました。
少し話がそれました。さて、ここ英国で転職活動をしたり友人の Software Engineer と交流しながら他社の様子を見てみた時、それなりに大きな規模の会社では、SRE をさらに分断して公募するケースに出会うことがあります。例えば、Observability に特化した SRE、Network レイヤーに特化した SRE、Configuration Management に特化した SRE、といった具合です。
この分け方は、理に適っていると思います。一重に「信頼性向上」といっても、Network 層の信頼性を向上させる技能と、Application 層の信頼性を向上させる技能は異なるでしょう。Series D/E 位までのスタートアップであれば、複数人の幅広い技術を持つ "SRE" に Hardware 層から Application 層までまるっと任せても良いでしょうが、ある程度会社の規模が大きくなって担当領域が細分化されていくと、"SRE for X", "SRE for Y" のような、「XXX の信頼性を向上させる Reliability Engineer」の存在が求められるようになるのです。
2018 年に "Designing Data-Intensive Application" を読み、いつか Databases に関わる仕事に就きたいと思っていた私は、自然の如く "SRE for Databases" という職種に魅力を感じました。事業会社の SRE として当時働いていた私は、RDBMS や KVS はもちろん、Kafka のような Streaming Application を含めて Polyglot なデータベースに触れる機会がありましたが、やはり Databases 専任の SRE から見える世界はどんなもんだろう、と夢を見て、(Graph) Databases を作っている会社に入社することにしました。
結論から言うと、この職種は非常にエキサイティングで私の性に合っていました。万人受けする職種かどうかはわかりませんが、Databases に携わりたいという思いと、大規模なアプリケーションの運用をしたいと言う思いが見事にマッチしています。会社に対する不満やカルチャーマッチなどは別の話ですが、SRE for Databases と言う職種には、現在愛着を感じてさえいます。
そもそも SRE なので、Software Engineering に対する強い技能とコミットが求められます。扱っているアプリケーションの規模がそもそも手運用では回せない規模なので、設計するにしても運用するにしても、コーディングが前提になってきます。自動化は大前提です。なので、コーディングができないと辛いでしょう。
また、Computer Science に対する経験も造詣も浅い自分の現状としては、幅広い領域で同時に Reliability Engineering を追求する技術力がありません。ですので、Databases と言う領域に特化して信頼性について考え抜けるので少し気が楽、と言うのはあります（といっても、Databases 自体は進化するし奥も深いので精一杯ですが）。
Google が体系化してくれたおかげで、信頼性をデザインする手法としての Site Reliability Engineering はアプリケーションを問わず適用できる抽象フレームワークになってはいるものの、実際の運用のことを考えると、対象技術について詳しければ詳しいほど、打てる手数は多くなります。
Rails application を運用するのに、Ruby が読み書きできて、Rails のコードが読めて、library を書いたり monkey patch 出来たりする方が、取れるメトリクスの種類も、直せるソフトウェア起因のバグも、大きく異なりますよね。
そんなこんなで、Graph Databases を運用する側に回っているわけですが、正直悩みもあります。私は Graph Database 特に自社のサービスが非常に良いサービスだと思っていますが、一方で既存の他の Databases 技術を置き換えて席巻するなどとは思っていません。Graph Databases には Graph Databases の強みがあり、RDBMS には RDBMS の強みがあり、KVS には KVS の強みがあります。
なので、Graph Databases 「だけ」を見ている現状は、正直もどかしくなる時もあります（無いものねだりですね）。MySQL も Kafka も懐かしい。DynamoDB も大好きです。Graph Databases は好きで、趣味プロジェクトでも良く使いますが、DDIA 本を読んで感化された自分としては、他の Databases の運用にもいつか戻りたいとは思っています。
今後は、しばらくは SRE for Databases の領域で働きたいですね。どこかのタイミングで、Database Engineer に転向して Databases 本体を開発する側に周ってみるのは面白いかなと考えています。もしくは、Data Engineer としてデータ基盤の構築やデータの価値を届けることに軸足をシフトしてもいいかなと。いずれにせよ、Databases に携わることはしていく気はしています。