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
tkitsunai
March 19, 2018
Technology
0
2.6k
hbstudy#82 SRE大全 ソフトウェアエンジニアリングによるToil削減
hbstudy#82のSRE大全で発表した内容です。橘内パートのみ収録。
tkitsunai
March 19, 2018
Tweet
Share
More Decks by tkitsunai
See All by tkitsunai
TDD実践を経て変わったこと
tkitsunai
6
4k
値オブジェクトでアプリケーションコードを改変しよう
tkitsunai
0
130
Go活
tkitsunai
0
140
Software Development in UZABASE SRE
tkitsunai
0
3.6k
Other Decks in Technology
See All in Technology
地図と生成AI
nakasho
0
660
公開初日に個人環境で試した Gemini CLI 体験記など / Gemini CLI実験レポート
you
PRO
3
290
An introduction to Claude Code SDK
choplin
3
3.2k
Maintainer Meetupで「生の声」を聞く ~講演だけじゃないKubeCon
logica0419
1
160
SAE J1939シミュレーション環境構築
daikiokazaki
0
120
The Madness of Multiple Gemini CLIs Developing Simultaneously with Jujutsu
gunta
1
2.4k
今日からあなたもGeminiを好きになる
subaruhello
1
550
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
netmarkjp
0
220
Building GoReleaser - from shell script to paid product
caarlos0
0
260
スプリントレビューを効果的にするために
miholovesq
9
1.6k
データ駆動経営の道しるべ:プロダクト開発指標の戦略的活用法
ham0215
2
230
Jitera Company Deck / JP
jitera
0
130
Featured
See All Featured
KATA
mclloyd
30
14k
What's in a price? How to price your products and services
michaelherold
246
12k
Statistics for Hackers
jakevdp
799
220k
Practical Orchestrator
shlominoach
189
11k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Documentation Writing (for coders)
carmenintech
72
4.9k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The World Runs on Bad Software
bkeepers
PRO
70
11k
The Cult of Friendly URLs
andyhume
79
6.5k
Producing Creativity
orderedlist
PRO
346
40k
Become a Pro
speakerdeck
PRO
29
5.4k
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!