この記事は、mediba Advent Calendar 2018 の12日目です。

注記

この記事は mediba 社に在籍していたときの記事です。
OKWAVE へ入社した際も立ち上げたので、いつか書きます。

ご挨拶

こんにちは。medibaのインフラストラクチャー部に所属している山下(やまぴー)です。
(GMOのぴーやまさんとは別人です。)
10年くらいエンジニアやっていて、9.5年くらいはインフラエンジニアしてます。
ギリギリ20代(俗に言うアラサー)です。

今回、SREチームを立ち上げて1年くらい経つので書いてみました。

medibaにはいくつものサービスがあり、システムがあります。
そのサービスたちを横断的に見てなにか役に立てないかな？という思いからSREチームを作ってみました。

実は「これをやるぞ！！」というスローガン的なものはカッチリ立てていません。
「こうしたい！」というより「こうありたい！」という思いが強かったので、ミッションとしては以下を掲げています。

上記に関連する施策をいくつか作っていますが、SREってどちらかというとゴールってないものなのかなって思います。

これはGoogleのSREでも定義されていることでした。
SLA/SLOを定めてそこに向かっていろいろやる、というやつですね。
今回はそこは重視せず、稼働率を高くするために今イケてないところ探して潰してこうぜをやってみました。

例えば

各サービスのサーバーに入っていろいろ見て、イケてないとこ探してみようよ
- Apacheの設定(MaxConnectionとかKeepaliveとか)が現状に合ってない
- おいおいrootでログインできちまうぞ(もちろんSecurityGroupで絞ってはいますが…)
- おいおいログがローテされてないぞ…
- ムダなEBSあるぞ
正しく監視されてるんだっけ？
- 見てみると足りてない項目が…
- 動くはずのないデーモンが監視されていて、ずーっとアラートあがってた

というような、システムの課題を見つけて開発エンジニアと一緒に対応していきました。

キャリアのサービスを担っているので、セキュリティにはかなり気を使っています。
EC2インスタンスの操作ログに関しても取得する必要があり、その仕組みの構築などを行いました。
OS標準のauditdを使用し、KinesisストリームでS3に叩き込むというものです。

当初td-agentでやろうと思いましたが、せっかくAWS使ってるのでKinesis使ってみようかなーと思った次第です。

(他社さんでどういうことやってるか知りたい…)

これを書きたかったんですよね。
実はこの方針は隠れミッションでした。
もともと、自分としては 「インフラエンジニアたるものおせっかい精神がないとあかん」 という思いの持ち主です。

こうしていくことで、サービスに対する愛着がわいたり、開発エンジニアとの距離が近くなるんじゃないかなという意図です。
(あと新卒エンジニアの教育の一環もあったり)

とにかく、今あるものをより良くついでに楽しく仕事しようぜっていうやつですね。
何よりも「エンドユーザのみならず、一緒に働く仲間の役に立つのが好き」という精神のもとにSREって成り立ってるんじゃないかな、と自分では思っています。

自分としても割とふわっと「SREやりたいんですよね」って言ってしまったので、当初はふわふわしていました。
そこで、部内のDevOpsチームやAWSインフラチームの人に手伝ってもらい、なんとか形になってきたような気がします。

自分自身、割と概念が主だっているので同僚にはアドバイスをよくもらいました。

SREとは別に、ミッションクリティカルなサービスのインフラ担当だったり、オンプレ周りのベンダーコントロールなどしていたので、最初はかなりてんてこ舞いでした。
チームのメンバーが率先して動いてくれた & なんとなく仕事の振り方がわかってきたので、進めていくうちに余裕が出てきました。

やっぱり人の役に立って、なおかつそれがチームとして体感できるのはすごくいい経験でした。
SREって固定化された概念ではないと思うんですよね。

自分たちでいろいろと決めてTryしていくのも含めて、SREとしての働き方なのかなという気がしました。