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
hbstudy#82 SRE大全 ソフトウェアエンジニアリングによるToil削減
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
tkitsunai
March 19, 2018
Technology
2.8k
0
Share
hbstudy#82 SRE大全 ソフトウェアエンジニアリングによるToil削減
hbstudy#82のSRE大全で発表した内容です。橘内パートのみ収録。
tkitsunai
March 19, 2018
More Decks by tkitsunai
See All by tkitsunai
TDD実践を経て変わったこと
tkitsunai
6
4.1k
値オブジェクトでアプリケーションコードを改変しよう
tkitsunai
0
170
Go活
tkitsunai
0
160
Software Development in UZABASE SRE
tkitsunai
0
3.9k
Other Decks in Technology
See All in Technology
ブラウザの投機的読み込みと投機ルールAPIを理解し、Webサービスのパフォーマンスを最適化する
shuta13
3
300
そのSLO 99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs
vtryo
0
580
拝啓、あの夏の僕へ〜あなたも知っているApp Runnerの世界〜
news_it_enj
0
240
React 19×Rustツール 進化の「ズレ」を設計で埋める
remrem0090
1
110
「QA=テスト」「シフトレフト=スクラムイベントの参加者の一員」の呪縛を解く。アジャイルな開発を止めないために、10Xで挑んだ「右側のしわ寄せ」解消記 #scrumniigata
nihonbuson
PRO
5
1k
20260507-ACL-seminar
satoshi5884
0
110
20260516_SecJAWS_Days
takuyay0ne
2
310
QAエンジニアはどうやって プロダクト議論の場に入れるのか?
moritamasami
2
420
セキュリティ対策、何からはじめる? CloudNative環境の脅威モデリングと リスク評価実践入門 #cloudnativekaigi
varu3
5
790
サンプリングは「作る」のか「使う」のか? 分散トレースのコストと運用を両立する実践的戦略 / Why you need the tail sampling and why you don't want it
ymotongpoo
4
170
アプリブロック機能のつくりかたと、AIとHTMLの不合理な相性の良さについて
kumamotone
1
250
多角的な視点から見たAGI
terisuke
0
130
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Designing for Performance
lara
611
70k
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
220
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
250
Technical Leadership for Architectural Decision Making
baasie
3
360
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.9k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.4k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.2k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
560
Site-Speed That Sticks
csswizardry
13
1.2k
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.5k
Transcript
hbstudy #82 SRE 大全 UZABASE SRE
ソフトウェアエンジニアリングによる Toil削減
自己紹介 橘内 孝幸 (Takayuki Kitsunai) UZABASE, Inc SRE Team Software
Engineer ServerSide中心にFrontまで幅広く担当。最近はArchitecture設計も多め 2015年にUZABASEにJoin Product Team(2015~) -> SRE Team(2017~) SRE Team内のツール開発、Operation自動化、Webアプリ自体のソフトウェア開発も担当 主に開発プロセスや手法の指針作りの部分でリードしています。
Table of Contents 1. UZABASEにとってのToilとは 2. Toilの計測 3. 自動化ツールの設計基本指針 (
DDD ) 4. 自動化ツールの設計基本指針 ( CA ) 5. 設計指針に基づいた作成ツール事例 6. まとめ
- シフト化されたタスク - インフラ依頼(各種アカウント作成など) - 差し込みタスク - 同じような依頼タスク - SPEEDAへの手動データ投入(運用)
- 購入データの投入 UZABASEにとってのToilとは
Table of Contents 1. UZABASEにとってのToilとは 2. Toilの計測 3. 自動化ツールの設計基本指針 (
DDD ) 4. 自動化ツールの設計基本指針 ( CA ) 5. 設計指針に基づいた作成ツール事例 6. まとめ
Toilの計測 • 計測ツールにTogglを採用 • 阻害プロジェクトを計測 • 昼会で日々共有 • 日別の割合計算
Toilの計測 より具体的な計測内容とその方針 • 緊急度が高く顧客指摘による不具合系(本番バグ) • ビジネス的に即時対応しなければならない改善タスク • 現行進んでいるプロジェクトを阻害するタスク • アラートによるジョブの対応
• カレンダー上で重複されたスケジュール • 輪番タスク、Toilとして認識しているタスク 1日での予定で、想定外のことを計測 差し込み率、Toil率の割合を算出していく
Toilの計測 Toil時間 / 1日
Table of Contents 1. UZABASEにとってのToilとは 2. Toilの計測 3. 自動化ツールの設計基本指針 (
DDD ) 4. 自動化ツールの設計基本指針 ( CA ) 5. 設計指針に基づいた作成ツール事例 6. まとめ
自動化ツールの設計基本指針 業務領域 (ドメイン) に寄り添う • ドメイン駆動設計 : Domain Driven Design
– 我々(あなた達)の業務は、ドメインとして知識化されている – ドメイン知識を噛み砕く(ドメインモデル化) – ドメインモデルは育てるもの(事業は成長する) Domain Model Domain Model ドメインを育てるということ:知識を噛み砕き、実装と結ぶ。
Table of Contents 1. UZABASEにとってのToilとは 2. Toilの計測 3. 自動化ツールの設計基本指針 (
DDD ) 4. 自動化ツールの設計基本指針 ( CA ) 5. 設計指針に基づいた作成ツール事例 6. まとめ
自動化ツールの設計基本指針 組織の成長を阻害しない • クリーンアーキテクチャ : Clean Architecture – 単方向の依存 –
Frameworkに依存しない – UIに依存しない – Data Storeに依存しない – テスト容易性 出典: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
自動化ツールの設計基本指針 なぜ、DDDとクリーンアーキテクチャ(CA)なのか? • システムは成長するため、システムのライフスパンはもっと短いはず – 置き換えをしやすく • 依存の考え方 – 業務がインフラに依存するのではなく、
– インフラが業務に依存する – コアとなるドメインは変わらないはず – 解決したいのはインフラではなく業務 • CAは思想 – CAはパターンの一つだが、考え方
Table of Contents 1. UZABASEにとってのToilとは 2. Toilの計測 3. 自動化ツールの設計基本指針 (
DDD ) 4. 自動化ツールの設計基本指針 ( CA ) 5. 設計指針に基づいた作成ツール事例 6. まとめ
設計指針に基づいた作成ツール事例 • Pacman: 新入社員のアカウント管理 – 採用計画も年々拡大 – 一人入社のたびに同じことをする – 一人退社のたびに同じことをする
– SaaS含む各アカウント作成 • Google Account • Redmine Account • VPN Account • Office 365 Account • etc…
設計指針に基づいた作成ツール事例 • Corporate/SRE TeamにとってのToil削減 – 10~15min/employee (SRE) – 25~30min/employee (Corporate)
• クリーン – SaaSを置き換え可能にする – コアドメインが類似 • エンジニアの良い練習場 – Golangの習得 – DDDの習得 – Architectureの習得 – Infrastructure as Codeの習得
• Toilを計測しよう – 差し込み・Toilのレートを分析しアクションする • DDDで作ろう – ドメインモデルを成長させて、コアなドメインを作る • Clean
Architectureは思想 – 学ぶのはアーキテクチャだけでなく、考え方。 – 単方向の依存と、レイヤ毎のクリーンさを保つ。 まとめ
ありがとうございました
Any questions? Thank you for listening!