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

Transcript

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

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

   　・ブログチーム SRE(2019/08 ~)

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

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

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

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

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

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

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

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

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

12. 異動することに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

34. まとめ

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