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
160
Go活
tkitsunai
0
160
Software Development in UZABASE SRE
tkitsunai
0
3.8k
Other Decks in Technology
See All in Technology
Babylon.js を使って試した色々な内容 / Various things I tried using Babylon.js / Babylon.js 勉強会 vol.5
you
PRO
0
190
Datadog で実現するセキュリティ対策 ~オブザーバビリティとセキュリティを 一緒にやると何がいいのか~
a2ush
0
180
Oracle Cloud Infrastructure(OCI):Onboarding Session(はじめてのOCI/Oracle Supportご利⽤ガイド)
oracle4engineer
PRO
2
17k
不確実性と戦いながら見積もりを作成するプロセス/mitsumori-process
hirodragon112
1
170
VSCode中心だった自分がターミナル沼に入門した話
sanogemaru
0
890
AWS DevOps Agent or Kiro の使いどころを考える_20260402
masakiokuda
0
140
I ran an automated simulation of fake news spread using OpenClaw.
zzzzico
0
110
Sansanの認証基盤を支えるアーキテクチャとその振り返り
sansantech
PRO
1
140
Zephyr(RTOS)でARMとRISC-Vのコア間通信をしてみた
iotengineer22
0
120
【Oracle Cloud ウェビナー】データ主権はクラウドで守れるのか?NTTデータ様のOracle Alloyで実現するソブリン対応クラウドの最適解
oracle4engineer
PRO
3
130
互換性のある(らしい)DBへの移行など考えるにあたってたいへんざっくり
sejima
PRO
0
520
【AWS】CloudTrail LakeとCloudWatch Logs Insightsの使い分け方針
tsurunosd
0
130
Featured
See All Featured
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
260
Agile that works and the tools we love
rasmusluckow
331
21k
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.2k
The Invisible Side of Design
smashingmag
302
51k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.9k
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
140
Navigating Weather and Climate Data
rabernat
0
150
Six Lessons from altMBA
skipperchong
29
4.2k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
290
Abbi's Birthday
coloredviolet
2
6.2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
95
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!