Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SREの異動と働き方 〜はてなブログ編〜 / Hatena Engineer Seminar...
Search
cohalz
February 05, 2020
Technology
0
2.4k
SREの異動と働き方 〜はてなブログ編〜 / Hatena Engineer Seminar #13
Hatena Engineer Seminar #13
https://hatena.connpass.com/event/164042/
の発表資料です
cohalz
February 05, 2020
Tweet
Share
More Decks by cohalz
See All by cohalz
toittaにOpenTelemetryを導入した話 / Mackerel APM リリースパーティ
cohalz
1
680
はてなにおけるfujiwara-wareの活用やecspressoのCI/CD構成 / Fujiwara Tech Conference 2025
cohalz
3
7.4k
はてなのSRE組織2024 / Road to SRE NEXT@福岡
cohalz
2
1.9k
SREのキャリア、 あるいは生態 / #ya8
cohalz
11
1.7k
カンファレンスのボランティアスタッフって何やるの? / DAIMYO Meetup #4
cohalz
0
180
小さなものでも Step Functions / Serverless Meetup Fukuoka Re:boot
cohalz
0
220
ECSのCI/CD改善と標準化の取り組み / JAWS FESTA 2023 in Kyushu
cohalz
8
7.3k
ecspressoへの貢献を振り返る / JAWS-UG コンテナ支部 #24 ecspresso MeetUp
cohalz
1
7.5k
はてなフォトライフをECSに移行した話 / Hatena Engineer Seminar #20
cohalz
1
19k
Other Decks in Technology
See All in Technology
風が吹けばWHOISが使えなくなる~なぜWHOIS・RDAPはサーバー証明書のメール認証に使えなくなったのか~
orangemorishita
15
5.8k
Claude Codeは仕様駆動の夢を見ない
gotalab555
23
6.8k
Serverless Meetup #21
yoshidashingo
1
130
AI時代の経営、Bet AI Vision #BetAIDay
layerx
PRO
2
2.1k
ロールが細分化された組織でSREと協働するインフラエンジニアは何をするか? / SRE Lounge #18
kossykinto
0
220
S3 Glacier のデータを Athena からクエリしようとしたらどうなるのか/try-to-query-s3-glacier-from-athena
emiki
0
230
九州の人に知ってもらいたいGISスポット / gis spot in kyushu 2025
sakaik
0
170
夏休みWebアプリパフォーマンス相談室/web-app-performance-on-radio
hachi_eiji
0
220
Amazon Bedrock AgentCoreのフロントエンドを探す旅 (Next.js編)
kmiya84377
1
150
Amazon Inspector コードセキュリティで手軽に実現するシフトレフト
maimyyym
0
120
薬屋のひとりごとにみるトラブルシューティング
tomokusaba
0
360
Telemetry APIから学ぶGoogle Cloud ObservabilityとOpenTelemetryの現在 / getting-started-telemetry-api-with-google-cloud
k6s4i53rx
0
150
Featured
See All Featured
How to Ace a Technical Interview
jacobian
278
23k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Gamification - CAS2011
davidbonilla
81
5.4k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
How to Think Like a Performance Engineer
csswizardry
25
1.8k
The Invisible Side of Design
smashingmag
301
51k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Code Review Best Practice
trishagee
69
19k
GraphQLとの向き合い方2022年版
quramy
49
14k
Transcript
SREの異動と働き方 〜はてなブログ編〜 Hatena Engineer Seminar #13 id:cohalz
自己紹介 ・id:cohalz / @cohalz ・株式会社はてな SRE (2018年新卒) ・SREチーム (~ 2019/08)
・ブログチーム SRE(2019/08 ~)
話すこと ・SREチームとブログチームについて ・異動 ・難しかったこと ・意識したこと ・改善したこと
SRE (Site Reliability Engineer)の仕事 ・サービス開発時の構築 ・各サービスの運用支援 ・安定稼働のための冗長化・キャパシティプランニング ・全社基盤の開発・運用 ・ミドルウェアやマネージドサービスの検証 これらを組織横断的に行うチームが社内に部として存在している
SREチームでの主な成果 https://developer.hatenastaff.com/archive/author/cohalz
最近のSREチーム http://slides.hokkai7go.jp/jtf2019-hatena-sre-scrum.pdf
そんな中 ブログチームへの異動を勧められる
はてなにおける異動 ・ユーザ向けサービスの他に受託開発など様々なチームがある ・個人の成長促進やチーム自体を改善するために異動を推奨している ・大体チーム配属から1年〜3年で異動することが多い
ブログチームへの異動(チームの事情) ・はてなブログという大きなプロダクトが抱える課題 ・インフラ周りの改善を継続的に行いたいが... ・DevとOpsが分離している状態ではなかなか進みにくい ・チーム付SREingという取り組みがうまく回っていたタイミング ・Mackerelやブックマークなど ・はてなブログタグのリリースが近い
DevとOpsの分離による課題 ・開発チーム側: ・SREチームにお願いする形になる ・コミュニケーションコストの増加 ・チームに運用知識が中々貯まっていかない ・SREチーム側 ・サービスの運用に時間を割き、本来の改善タスクが進まなくなる
ブログチームへの異動(個人の事情) ・キャリアの関係 ・SREチームはサービスを持っているわけではない ・ミドルウェア運用経験などが積みにくい ・MySQLやElasticsearchなど ・AWSのサービス知見を開発チームでも活用していきたい
異動することに
そうして はてなブログ初のSREが誕生
とはいえ大変なこともたくさん
異動によって起きた変化 ・コミュニケーション ・大きなシステムを運用する怖さ ・キャッチアップ
コミュニケーション ・チームメンバーが変わることによる難しさ ・SREチーム: 上司もチームメンバーもSREの分野に大きな理解があった ・ 今は逆にSREingに詳しい人があまりいない ・デザイナーやプランナーなど多職種に渡る
コミュニケーションで工夫した点 ・期初に行う1on1の他に、ディレクターの提案でドラッカー風 エクササイズを実施してもらった ・どういったことを期待されて、どういったことができるのかお互いに把握でき、 認識のズレが少なくなってとても良かった
コミュニケーションで工夫した点 ・別の職種の相手にも伝わるように、背景も充実させてコミュニケーションをす る ・後から他の人が見る際にも役に立つので損はない
大きなシステムを運用する怖さ ・2011年からサービス開始して、9年目のプロダクト ・関連システムも複数ある ・知識も経験もまだ未熟で、なにか障害を起こすかもしれない
意外とうまくやっていけている ・他の人も積極的に協力してくれる体制 ・はてなブログ自体の冗長性の高さ ・非難をせず、挑戦を応援する文化 異動時のSREチームからの相談
批判をせず、挑戦を応援する文化 ・障害を起こしたときもチームで役割分担して復旧に向かう ・その後、一緒に再発防止策を考える ・障害を起こした人を非難しない ・はてなのバリューズにも「挑戦が好き」がある ・https://hatenacorp.jp/recruit/values もちろん考えなしに無茶をやっていいというわけではない
キャッチアップ ・緊急度の低いオペレーションからやってみる ・PWG(Performance Working Group)の運営を行う ・パフォーマンスを確認する会 ・メトリクスやエラー数の変化からどういう状態か把握してく ・チームメンバーへタスクを渡す練習にもなる
緊急度の低いオペレーションをきっかけに ・EC2メンテナンス ・ペアオペ・ドキュメント化を徹底する
開発合宿への参加 ・オフィスを離れ、チームを組んで3日間作業する「開発合宿」という社内イベン トがあり参加した ・「ブログのパフォーマンス改善」というテーマで取り組んだ
開発合宿への参加その後 ・パフォーマンスの確認・改善だけでなく、知見の伝授にもなった ・開発合宿以後もスピード感を持ってパフォーマンス改善に取り組めるように
はてなブログ タグのリリース ・ミドルウェアの検証や運用のためのダッシュボードを作る ・ユーザに使われるサービスの構築・運用に慣れることができた
チームで運用を回していく ・はてなブログという大きなシステムを一人でどうにかできるのか ・=> No ・じゃあ、よりスケールする方向に ・チームでオペレーションできるようにドキュメントを整備 ・ミドルウェアの設定もチームでレビュー ・さらに自動化できないか考える
どのような改善を行ってきたか
主に改善していったところ ・ドキュメント化 ・自動化 ・健全化
ドキュメント化: Scrapboxの活用 ・手順がSREチーム側にあるものを、チームのScrapboxに移設 ・コピペするだけではなく実際に手を動かして作り、アップデートする ・新しく、誰でも作業できるようなドキュメントになった
健全化: アラートの整理 ・夜や土日にアラートが多く出るという問題があった ・サービスが落ちているのかわかりにくい ・起きたアラートを振り返り、どういったものだったか分類するように ・即時対応が不要であれば通知されないようにした ・サービスも大事だけどチームが健全に運用できるように
自動化: 証明書の更新 ・証明書の更新期限が近く更新する必要があった ・証明書の購買申請から配置までを行う必要があった ・過去に対応した人がいない、フローも変わっていて難しい ・検証環境ではまた違う手順を踏む必要があった ・これを自分以外でもやれるようにするかというと...?
自動化: 証明書の更新 ・SREチーム時代に作った自動更新システムを導入 ・検証環境と本番環境で同じ仕組みに統一 ・仕組みがおかしくなっても気付けるように ・PWGでメンバーに構成やドキュメントを紹介
まとめ
まとめ ・異動をきっかけに、コミュニケーション・知識を向上させていった ・難しいこともあるけれど、他の人も巻き込んでうまく回しています ・今後のはてなブログの改善にご期待ください