SRE session #2 Welcome Talk 'Eliminating Toil'

Transcript

1. SRE Session # “Eliminating Toil” Welcome Talk 2019年6⽉5⽇(⽕) ⼭⽥直⾏
2. ⾃⼰紹介 • ⼭⽥直⾏(Naoyuki YAMADA) • サイバーエージェント アドテク本部
 Strategic Infrastructure Agency いろいろなプロダクトのインフラ‧SRE業務 アドバイス業務もあるがほとんどは実務 • XTech Startup Studio エンジニア(個⼈事業主)
 新規プロダクトのバックエンド（サーバーサイド‧インフラ開発） • 来週6/12からのSREcon Asia/Pacificに参加予定です !TBUVMMZ DIPLLPZBNBEB
3. .今⽇のテーマ’Eliminating Toil’について .最近の私の業務でのトイルとの関わり
4. 今⽇のテーマ ’Eliminating Toil’について
5. 今⽇のテーマ: Eliminating Toil • トイル（Toil）とは？ ʲ1໊ʳ 1.͍ۤ͠࢓ࣄɺࠎંΓɺ࿑ۤ ʲ1ࣗಈʳ 1.ࠎંͬͯಇ͘ 2.ɾHe had to toil all night and day to finish the job. : ൴͸ɺ࢓ࣄΛऴ͑ΔͨΊʹன΋໷΋ͣͬͱਫ਼Λग़ͯ͠ಇ͔ͳͯ͘͸ͳΓ·ͤ ΜͰͨ͠ɻ ʲ1ଞಈʳ 1.ʙΛർΕͤ͞Δ ʲ2໊ʳ 1.ʤ֫෺ΛัΒ͑ΔͨΊͷʥ໢ɺωοτ ʲ2ଞಈʳ 1.ʤ֫෺Λʥ໢ʦωοτʧͰัΒ͑Δ ʲϨϕϧʳ7ɺʲൃԻʳtɔ́il、ʲˏʳτΠϧɺʲมԽʳʬಈʭtoils ʛ toiling ʛ toiled ʢtoilͷҙຯɾ࢖͍ํʛӳࣙ࿠ on the WEBɿΞϧΫ https://eow.alc.co.jp/search?q=toilʣ
6. 「SRE本第五章 トイルの撲滅」より • トイルとは、プロダクションサービスを動作さ せることに関する作業で、⼿作業で繰り返し⾏ われ、⾃動化することが可能であり、戦術的で ⻑期的な価値を持たず、作業量がサービスの成 ⻑に⽐例するといった傾向を持つものです。
7. トイルに⾒られる傾向 • ⼿作業であること • 繰り返されること • ⾃動化できること • 戦術的であること（≠戦略的でない、予測的でない、場当たり的である） • ⻑期的な価値を持たないこと • サービスの成⻑に対してO(n)であること
8. トイルは少ないほうが良い理由 • 典型的なSREの業務は「ソフトウェアエンジニアリング」「システムエン ジニアリング」「トイル」「オーバーヘッド（事務作業など）」に分けら れるが、GoogleのSREの組織では、運⽤業務(トイル)を各⼈50%以内に抑 えようという⽬標がある • トイルが多すぎると、「キャリアの停滞」「モラルの低下」「混乱の発 ⽣」「（開発）進捗速度の低下」「習慣づけ」「摩擦の発⽣」「信義違 反」などの問題を起こしてしまう。
9. 最近の私の業務でのトイル との関わり
10. 現在の担当プロダクト • 創業10年の⼦会社、システムが5年くらいほとんど更新されていない（と いうか新規事業は上や横にくっつけて構築されている）広告システム • エンジニアは10⼈程度 インフラは私ともう1.5⼈くらい（兼務）
 SRE的ポジションは専任では私のみ • ⼦会社内のインフラエンジニアの退職と同時に、インフラ担当として ジョインして3ヶ⽉ほど • 売上‧利益は社内でも指折りの規模
11. • GitHubレポジトリ120個 • サーバー（&コンテナ）500台 • オンプレミス（ベアメタルサーバー、KVM）, OpenStack(バージョン2系 統)、Docker Swarm, GCP(Kubernetes)などオールスター状態 • chefサーバー4系統, Ansibleも利⽤ • Jenkinsマスター10台以上 • PHP, Rails, Go⾔語が⼊り乱れる • ミドルウェア‧ライブラリはほとんどが2011年〜2016年 • でも致命的な障害なく動き続けていて、利益も⽣んでいる
 (レガシーだけどHA構成はしっかりしてる)
12. 発⽣しているトイル • ディスクがいっぱいになる • プロセスが多重起動してOOMになる • Dockerコンテナがなぜか落ちる • 急激な負荷増⼤に対応を迫られる • ログをsshログインしてtailして⾒る • chatworkに⾶んだアラートがどこから送信されたのか、から調査 • ビジネスロジックの追加のたびにnginxの設定ファイルに追加作業 • 脆弱性対応（外部組織の監査で指摘を受けたものを改修）
13. トイルと向き合う • インフラをすべて理解している⼈はいないが、業務ロジックが分かる ⼈が複数⼈いるのは救いだった（「これは何に使っているのか」がだ いたいヒアリングできる）
 →サーバー構成図、データベース構成、CI/CDの構成を整理‧可視化 • インフラを⼿作業で変更＆再起動をやってたのを1つずつ⾃動化
 →chefのメンテナンス再開、ロードバランサ操作のスクリプト化、運 ⽤ドキュメントの作成、監視のみなおし
14. 本当に減らさないといけないもの • 開発エンジニアのトイルがすごい、属⼈化している 障害対応‧データ復旧‧都度の問い合わせ対応など • 業務ロジックを組んでいる開発エンジニアのトイルの削減にも取り組 んでいきたい
15. ありがとうございました 今⽇はよろしくおねがいします！