SREの異動と働き方〜はてなブログ編〜 / Hatena Engineer Seminar #13

by cohalz

Slide 1

Slide 1 text

SREの異動と働き方〜はてなブログ編〜 Hatena Engineer Seminar #13 id:cohalz

Slide 2

Slide 2 text

自己紹介・id:cohalz / @cohalz ・株式会社はてな SRE (2018年新卒) 　・SREチーム (~ 2019/08) 　・ブログチーム SRE(2019/08 ~)

Slide 3

Slide 3 text

話すこと・SREチームとブログチームについて・異動　・難しかったこと　・意識したこと・改善したこと

Slide 4

Slide 4 text

SRE (Site Reliability Engineer)の仕事・サービス開発時の構築・各サービスの運用支援・安定稼働のための冗長化・キャパシティプランニング・全社基盤の開発・運用・ミドルウェアやマネージドサービスの検証これらを組織横断的に行うチームが社内に部として存在している

Slide 5

Slide 5 text

SREチームでの主な成果 https://developer.hatenastaff.com/archive/author/cohalz

Slide 6

Slide 6 text

最近のSREチーム http://slides.hokkai7go.jp/jtf2019-hatena-sre-scrum.pdf

Slide 7

Slide 7 text

そんな中ブログチームへの異動を勧められる

Slide 8

Slide 8 text

はてなにおける異動・ユーザ向けサービスの他に受託開発など様々なチームがある・個人の成長促進やチーム自体を改善するために異動を推奨している　・大体チーム配属から1年〜3年で異動することが多い

Slide 9

Slide 9 text

ブログチームへの異動(チームの事情) ・はてなブログという大きなプロダクトが抱える課題　・インフラ周りの改善を継続的に行いたいが... 　・DevとOpsが分離している状態ではなかなか進みにくい・チーム付SREingという取り組みがうまく回っていたタイミング　・Mackerelやブックマークなど・はてなブログタグのリリースが近い

Slide 10

Slide 10 text

DevとOpsの分離による課題・開発チーム側: 　・SREチームにお願いする形になる　　・コミュニケーションコストの増加　　・チームに運用知識が中々貯まっていかない・SREチーム側　・サービスの運用に時間を割き、本来の改善タスクが進まなくなる

Slide 11

Slide 11 text

ブログチームへの異動(個人の事情) ・キャリアの関係・SREチームはサービスを持っているわけではない・ミドルウェア運用経験などが積みにくい　・MySQLやElasticsearchなど・AWSのサービス知見を開発チームでも活用していきたい

Slide 12

Slide 12 text

異動することに

Slide 13

Slide 13 text

そうしてはてなブログ初のSREが誕生

Slide 14

Slide 14 text

とはいえ大変なこともたくさん

Slide 15

Slide 15 text

異動によって起きた変化・コミュニケーション・大きなシステムを運用する怖さ・キャッチアップ

Slide 16

Slide 16 text

コミュニケーション・チームメンバーが変わることによる難しさ・SREチーム: 上司もチームメンバーもSREの分野に大きな理解があった・今は逆にSREingに詳しい人があまりいない　・デザイナーやプランナーなど多職種に渡る

Slide 17

Slide 17 text

コミュニケーションで工夫した点・期初に行う1on1の他に、ディレクターの提案でドラッカー風　エクササイズを実施してもらった・どういったことを期待されて、どういったことができるのかお互いに把握でき、認識のズレが少なくなってとても良かった

Slide 18

Slide 18 text

コミュニケーションで工夫した点・別の職種の相手にも伝わるように、背景も充実させてコミュニケーションをする　・後から他の人が見る際にも役に立つので損はない

Slide 19

Slide 19 text

大きなシステムを運用する怖さ・2011年からサービス開始して、9年目のプロダクト・関連システムも複数ある・知識も経験もまだ未熟で、なにか障害を起こすかもしれない

Slide 20

Slide 20 text

意外とうまくやっていけている・他の人も積極的に協力してくれる体制・はてなブログ自体の冗長性の高さ・非難をせず、挑戦を応援する文化異動時のSREチームからの相談

Slide 21

Slide 21 text

批判をせず、挑戦を応援する文化・障害を起こしたときもチームで役割分担して復旧に向かう　・その後、一緒に再発防止策を考える　・障害を起こした人を非難しない・はてなのバリューズにも「挑戦が好き」がある　・https://hatenacorp.jp/recruit/values もちろん考えなしに無茶をやっていいというわけではない

Slide 22

Slide 22 text

キャッチアップ・緊急度の低いオペレーションからやってみる・PWG(Performance Working Group)の運営を行う　・パフォーマンスを確認する会　・メトリクスやエラー数の変化からどういう状態か把握してく　・チームメンバーへタスクを渡す練習にもなる

Slide 23

Slide 23 text

緊急度の低いオペレーションをきっかけに・EC2メンテナンス　・ペアオペ・ドキュメント化を徹底する

Slide 24

Slide 24 text

開発合宿への参加・オフィスを離れ、チームを組んで3日間作業する「開発合宿」という社内イベントがあり参加した・「ブログのパフォーマンス改善」というテーマで取り組んだ

Slide 25

Slide 25 text

開発合宿への参加その後・パフォーマンスの確認・改善だけでなく、知見の伝授にもなった・開発合宿以後もスピード感を持ってパフォーマンス改善に取り組めるように

Slide 26

Slide 26 text

はてなブログタグのリリース・ミドルウェアの検証や運用のためのダッシュボードを作る・ユーザに使われるサービスの構築・運用に慣れることができた

Slide 27

Slide 27 text

チームで運用を回していく・はてなブログという大きなシステムを一人でどうにかできるのか　・=> No ・じゃあ、よりスケールする方向に　・チームでオペレーションできるようにドキュメントを整備　・ミドルウェアの設定もチームでレビュー　・さらに自動化できないか考える

Slide 28

Slide 28 text

どのような改善を行ってきたか

Slide 29

Slide 29 text

主に改善していったところ・ドキュメント化・自動化・健全化

Slide 30

Slide 30 text

ドキュメント化: Scrapboxの活用・手順がSREチーム側にあるものを、チームのScrapboxに移設・コピペするだけではなく実際に手を動かして作り、アップデートする　・新しく、誰でも作業できるようなドキュメントになった

Slide 31

Slide 31 text

健全化: アラートの整理・夜や土日にアラートが多く出るという問題があった　・サービスが落ちているのかわかりにくい・起きたアラートを振り返り、どういったものだったか分類するように　・即時対応が不要であれば通知されないようにした・サービスも大事だけどチームが健全に運用できるように

Slide 32

Slide 32 text

自動化: 証明書の更新・証明書の更新期限が近く更新する必要があった　・証明書の購買申請から配置までを行う必要があった　・過去に対応した人がいない、フローも変わっていて難しい・検証環境ではまた違う手順を踏む必要があった・これを自分以外でもやれるようにするかというと...？

Slide 33

Slide 33 text

自動化: 証明書の更新・SREチーム時代に作った自動更新システムを導入・検証環境と本番環境で同じ仕組みに統一　・仕組みがおかしくなっても気付けるように・PWGでメンバーに構成やドキュメントを紹介

Slide 34

Slide 34 text

まとめ

Slide 35

Slide 35 text

まとめ・異動をきっかけに、コミュニケーション・知識を向上させていった・難しいこともあるけれど、他の人も巻き込んでうまく回しています・今後のはてなブログの改善にご期待ください