doridoridoriand’s diary

主に技術的なことを書いていく予定(たぶん)

SREと私と時々障害

ポエム

これは SRE Advent Calendar 2019 25日目の記事です。
世の中はクリスマスですね。特に意識していなくても浮足立ってしまうのは、まだ子供なせいなのでしょうか。
タイトルの付け方が何となく一昔前な気がするかもしれませんが、これしか思いつかなかったのと、結構気に入っているのでこのままでいきます。

注意: この記事はポエムが含まれております

現在とSREになるまでの変遷

現在私はとあるメディアサービスを提供している会社のSREチームでエンジニアとして働いています。所属しているチームは、

  • インフラエンジニア(私): 1人
  • バックエンドエンジニア: 3人

計4人で構成されています。

ここでSREチームに所属するまでの、私の変遷をご紹介したいと思います。

  • 2016年6月~12月 バックエンドエンジニアとして新卒で現在の部署に配属。とあるメッセンジャーアプリのAPIの開発 + Webフロントエンドの開発に従事。
  • 2017年3月より、インフラ局に所属。インフラエンジニアに転向し、先輩とともにインフラ業務に従事。12月に先輩が退職し、1人体制となる。
  • 2018年1月から、バックエンドエンジニアとしてインフラ業務に従事。
  • 2018年10月SREチーム発足。現在に至る。

元々バックエンドエンジニアでしたので、複数のLLを業務レベルで書くことは可能でした。私をインフラに誘ってくれた先輩は以下の理由によりインフラにも向いていそうだなと思ったようです。

  • 内定者時代からAWSの経験があった
  • サーバーのスペックに敏感だった
  • IDEやVSCodeを使わず、ターミナルで開発していた(コンソールのVimで開発してました)

インフラも面白そうだなと思っていたので、そこまで迷うこともなく(コーディングから離れることに対する一抹の不安はありましたが)転向をお願いしました。 それから10ヶ月程度、現在の稼働サービスのインフラの状況から、運用に必要な実務レベルでのインフラ知識などを教えていただきました。

ここで転機となったのはその先輩の退職です。

  • サービス規模、ユーザー数拡大に負荷増大や、それに伴う既存の設計の問題の露呈
  • 老朽化に伴う移行作業
  • 最新技術等の導入
  • 障害対応業務

バックエンドエンジニアと協力して作業するのはもちろんですが、インフラ視点からのアドバイスをできるのが1人になってしまいました。
またインフラサイドにおける細かな運用業務も基本的には1人になりました。

今までのやり方をそのままやるのでは潰れてしまうので、私はできる限り自動化・容易化することに注力しました。ここでバックエンドエンジニアの力が活きてきました。
改善業務の一部として以下を行いました。

半年くらいをかけて、大小様々ですが100個程度のスクリプトを作成しました。このスクリプト達のおかげで、1人でもなんとかなるところまで持ってこられました。

SREの発足

次に転機となったのはSREチームの発足です。Googleが2017年の1月にSRE本のテキストを無料公開し、業界的にも徐々にSREに関して注目が高まっている頃でした。

2018年10月頃、開発責任者からSREチームの発足を告げられます。この時私はSREとしてうまく稼働できるかに関してはあまり自信がなく、現状のインフラ＋αになる程度ではと思ってました。 これに関しては、SREと活動している現在も、私のミッションは主にインフラ+αなのですが、結果的に問題ないのではと思っています(※後述します)

バックエンドチームから切り離され、SREチームとなったメンバーは手探りで自分たちのミッションを決めていく必要がありました。そこでまずは本家に従おうということで、SRE本のチームでの輪読会を開きます。 ここから現在の開発組織における問題と対応策をみんなで話し合いました。

GoogleがO'Reillyから出版している「Site Reliability Engineering」は非常にボリュームがあり、また全部を輪読してもただの読書会になることが目に見えていたので、重要なところをかいつまみ、担当を割り振って実施しました。

一通りSREとしての先行事例を知ることができたので、次は自分たちの事業部に当てはめる作業になります。あくまでもGoogleの事例は、

「世界的に利用されているサービスを、複数の国と地域にまたがった開発組織を利用して、継続的かつ安定的なサービス運用する」

ために必要な仕組み等が多分に含まれています。

Googleのサービス群に比べれば小規模であり、ほとんどのサービス利用者が国内である、日本向けのサービスを展開している現在の事業部にそのまま当てはめるのは現実的ではありません。 また、SREチームは新規技術の開発というミッションも負っていたので、この時点で通常のSREチーム同様の働きはできなくなりました。

まずはじめにチームとして以下の内容に関して取り組むことになりました。

  • SLI/SLOを定義
  • 属人化している障害対応をもっと開発チーム全体で満遍なくできるようにする
  • 負荷試験の継続的な実施のための整備
  • ログ周りの整備可視化の充実化
  • トイルの継続的な改善・解消

SLI/SLOを定義に関しては私のミッションの1つだったので、実施背景を説明します。
この時すでにSREという単語が世間的にもある種のバズワードになっており、それに付随する単語も、聞いたことはあるが、具体的にどのようなもの分かっていないという状況だったと思われます。 そこでまずはSREとは何か、何のために存在するのか、目的は何なのかをはっきりさせるため、事業部のエンジニア全員が集まる開発定例にて勉強会を実施し、単語の定義及びミッションの共有の必要があると考え、実施しました。
なお、開発状況及び私自身のミッションの変更などにより、現在は別の担当者に引き継がれております。

状況の変化

現在の事業部の開発はビジネスに寄り添った開発スタイルを採っています。よって開発項目もビジネスの方向性の変更などにより俊敏に変更する必要があります。これ自体はとても素晴らしいことだと思っているので問題は無いのですが、SREチームのメンバーがSRE業務ではなく新規機能開発の方に比重を置かなくてはいけない時間が多くなりました。

またSREチームあるあるなのかもしれませんが、使用ミドルウェアのアップデートなど、定常的なインフラ業務が減っておらず、またインフラエンジニアが私だったこともあり、SREチームというよりは、バックエンドチームの新規機能開発チーム+インフラというような状況になっていました。

私自身も別のサービスのインフラを担当するなど、現在所属している事業部にとどまらず、現在出向している子会社のインフラを全般的に見るようになってきて、別チームと仕事をすることも増えてきました。

現在とこれから

現在はSREチームはKubernetesを利用したマイクロサービス基盤の開発・運用チームとなっております。現在EC2上で動いているアプリケーションも徐々にこのマイクロサービス基盤に移行されていく予定とのことです。
アプリケーションの移行に関しても、インフラエンジニアがメインで関わることなく、 バックエンドエンジニアが主体となって進められる状況を生み出せたことはとても良かったと考えております。

私は現在以下のミッションを実施しております

  • カオスエンジニアリングの導入・実施
  • 視聴品質の定常的な計測・可視化
  • 旧型インフラの改廃
  • 他サービスのインフラ・バックエンドエンジニア

インフラ半分SREのようなもの半分といったところでしょうか。
〇〇エンジニアといったロールが元々好きでは無いので(専門性は別にロールが無くても増やすことは出来ると考えているので)、個人的には望ましい状況になってきております。

SREというチームが必要なのではなく、SREの思想を少しでもバックエンドエンジニアが持っていることのほうがとても重要なので、以上のミッションを通して、バックエンドエンジニアにSREの思想及びその根底にあるインフラの知見を布教できればと考えております。

障害の話一度もしませんでしたね。。笑
正直なところ、ここには書けないので面識ある方はランチや飲みなどに誘ってください。話せる範囲で話します笑