非ITの事業会社にSREと言わずにSREを持ち込んだ

非ITの事業会社にSREと言
わずにSREを持ち込んだ
SRE NEXT 2022, 2022-05-15
Toshiaki Baba
Twitter: @netmarkjp
株式会社X-Tech 5 取締役CTO
https://x-tech5.co.jp/
株式会社iCARE技術顧問（インフラ）
https://dev.icare.jpn.com/tech_adv/

View Slide

SRE NEXT 2022 非ITの事業会社にSREと言わずにSREを持ち込んだ
お断り
2
事実ベースのお話ですが、諸般の
事情で意図的にフィルタすること
があります

View Slide

ことのおこり
3
不安なことがあって、、、
運用、インフラ、クラウドに詳しいばばさん、
助けてもらえませんか、、、

View Slide

自己紹介
馬場俊彰（ばばとしあき） Twitter: @netmarkjp
株式会社X-Tech 5 取締役 CTO、株式会社iCARE技術顧問（インフラ）
電気通信大学人間コミュニケーション学科（2004年卒）
→社会人（SCC→ハートビーツ→X-Tech 5）
→産業技術大学院大学（AIIT）情報アーキテクチャ専攻（2011年卒）
主な守備範囲：Webシステムのインフラ・ミドルウェア全般、モニタリング、
チューニング、プログラミング（Python、Go）
4
Amazon著者ページ https://www.amazon.co.jp/%E9%A6%AC%E5%A0%B4-%E4%BF%8A%E5%BD%B0/e/B004Y4SUBY

View Slide

むかしむかし　あるところに...
5

View Slide

状況
● 過去に別案件でお世話になった方からご連絡
● いま携わっている、事業会社の業務システムで不安なことがある
・フルリニューアル・クラウド化→切り替え失敗を経て、1年越しの繁忙期
リベンジ
・いろいろあって、開発会社の移管を行う
→改めて本番利用するにあたり運用や監視全般が不安
→開発担当者（社）移管に伴うクラウド関連のノウハウとりこぼしも不安
→開発担当者（社）／インフラ担当者（社）の守備範囲の隙間埋めも不安
※エスアールイーのエの字も出てない 6

View Slide

さくせん
7
● まずは成果を出すための構造を整える
● 少しずつでも継続的に進捗を出すためにOODAループを回す
● 専門家として全体を俯瞰するが、抑えるポイントはユーザ視点・業務視点で
重要なポイントから手を付ける
情報流通プラットフォーム
知識関係性
成果（実益）
変化の激しいWebの世界でコンスタントに局面局面で勝つ方法論「OODAループ」
https://speakerdeck.com/netmarkjp/bian-hua-falseji-siiwebfalseshi-jie-dekonsutantonij
u-mian-ju-mian-desheng-tufang-fa-lun-oodarupu
想定した"成果のために必要な構造"

View Slide

0ヶ月目（プロジェクト参画前）
まずはプラットフォーム整備
● キックオフミーティングをする
● コミュニケーション基盤を決める（チャット、チケット）
● ドキュメント基盤を決める（Wiki、ファイル）
● 定例会スケジュールを決める
→ツールはSlackとBacklogが定番
SEE ALSO:
Webエンジニアのための監視システム実装ガイド
8
知識関係性
成果（実益）

View Slide

1ヶ月目
システムとステークホルダーに詳しくなり、仲良くなる
→リテラシを高め、会話に参加できるようになる
● いまあるドキュメントを読む
○ しっかり：目的・概要・アーキテクチャデザイン意図・外部連携箇所・業務的に重要な処理
○ 参考程度に：詳細設計、ER図、xx一覧など、実装レベルのドキュメント。CIで自動生成され
るものは信用できるが、それ以外は参考程度にする
● AWS Management Consoleを見て利用しているコンポーネントを把握する
● ソースコードを見ておおまかな動作や処理内容を把握する
並行して、チャットや定例会を通じて積極的にコミュニケーションし、ステーク
ホルダーのスタンスやポリシー、実現力の程度（期待値）を把握する
9
知識関係性
成果（実益）

View Slide

1ヶ月経過後の状況
● コードを書いてロジックを修正する範囲では
問題なく・不安なく移管できた
● 繁忙期の本番運用に対する自信／不安はまちまち
● 各ステークホルダーに対する双方向の期待値が噛み合っていない
○ 開発／インフラ担当者（社）は「わかる範囲でやるべきことはやっている」
○ 業務視点・ユーザ視点での "やるべきこと" は不明なまま
● 新たに最優先で対処すべき課題が発覚
○ 負荷テストはしていない。スペックアップはするつもり
○ クラウド利用費用が予算に対して4倍かかっている
10
知識関係性
成果（実益）

View Slide

1ヶ月経過後のアクション
● 対応の優先順位を決定
○ コスト最適化、パフォーマンス最適化、モニタリング、インベントリ管理などのテーマの中
から優先順位を決定
○ コストがあまりにもだったのでコスト最適化からに決定
● 優先順に従って順次対応
○ 解決までのアプローチの道筋を示し、実際に回してみせる
○ 週次でOODAを回す
○ 定例会までに調査（Observe）、考察（Orient）、判断指針提示、判断の提案
○ 定例会で判断（Decide）
○ 次回定例会までに実行（Action）
○ →毎週10+ページのレポート 11
知識関係性
成果（実益）

View Slide

例：AWSコスト最適化の週
タイトル（ファイル名）：コスト削減検討の会話元ネタ
● 現状のコストについておさらい
○ 何月にいくらだった、どう推移してきた...
● いままでやってきたコスト関連の作業を時系列でおさらい
○ a月b日にスペックアップ...
● AWSの費用特性をおさらい
○ インスタンスサイズが倍になると費用も倍。RDSクラスタだと倍×台数なので影響がデカい
○ キャパシティ調整には垂直スケーリングと水平スケーリングがあって...
● アプローチのポリシーをおさらい
○ 削除漏れみたいな明らかに無駄なものを削るのはやるとして、いちばんデカいところから順にアプ
ローチすべき...
● アプローチとして考えられるアイデアをつらつらと挙げる
○ 例：RDSインスタンスサイズを下げる
→月xx円程度の削減可能性あり。その際のネックはCPU利用率。CPU利用率が高い理由はSELECT ...
というクエリで、このクエリはyyyテーブルのzzz列にインデックスを張ると改善可能性あり。ス
ペックダウンによりメモリ容量も減るがデータ量がnMBなのでリスクは低い
● データ集
12

View Slide

2ヶ月目以降
● 定例会をリードして、OODAを回す
○ わたしたちはチームが離陸するためのカタパルト的な役割
● テーマごとに、まず考え方を示し、やって見せ→任せ
● 迅速・確実を志向するとソフトウェアエンジニアリングで課題解決するのが
スマートだというのを示していく
（「手作業を避けよう」という声かけが通りやすい場合もあり）
● 各テーマ、3周目くらいから各担当者（社）にお任せできるようになった
● 「ばばさんがやっている取り組みって一般に何て言うんですか？」
→「最近はSREって呼ばれてます」
13
知識関係性
成果（実益）

View Slide

めでたし　めでたし
14

View Slide

振り返り：さくせん
15
● まずは成果を出すための構造を整える
● 少しずつでも継続的に進捗を出すためにOODAループを回す
● 専門家として全体を俯瞰するが、抑えるポイントはユーザ視点・業務視点で
重要なポイントから手を付ける
知識関係性
成果（実益）
変化の激しいWebの世界でコンスタントに局面局面で勝つ方法論「OODAループ」
https://speakerdeck.com/netmarkjp/bian-hua-falseji-siiwebfalseshi-jie-dekonsutantonij
u-mian-ju-mian-desheng-tufang-fa-lun-oodarupu
想定した"成果のために必要な構造"
👍
👍
👍

View Slide

振り返り：幸運だったこと
● 良好な関係性が築けた
● OODAループが回せた
○ 移管後の体制はHRTを満たしていた（Humility / Respect / Trust）
○ 改善が歓迎される状況だった（各位が危機的状況を自覚していた）
○ 開発担当者（社）、インフラ担当者（社）ともに実現力があった
○ 決裁権を持つ上席がプロジェクトに参加し都度判断していた
○ ユーザ視点・業務観点で優先度や影響について会話できた
○ 事業会社としてプロダクトを管掌し推進せねばならないという意識があった
16

View Slide

振り返り：学び
● 成果を出す構造が整っていると、全員が能力を発揮しやすい
● OODAを回すと変化が起きる。つまり改善が進捗する
● ユーザにとってだいじなことから順番に押さえていくとスムーズ
● OODAを素早く回したり、ユーザにとってのシステム価値を高め、それを少
人数で継続的に実現しようとすると、自然とSREのプラクティスに近づいて
いく
○ 状態を観測しメトリクスをもとにデータで物事を判断する
○ ソフトウェアエンジニアリングを活用する、Toilを削減する
自分的good point
● テーマごとに考え方を示して、まずやってみせて、次に伴走した
● 正しくやることより課題解決が進捗することを重視した 17
知識関係性
成果（実益）

View Slide

どうして？　どうして？
18

View Slide

成果に至る構造：外観
● 良好な関係性は土台であり前提条件
○ 不足の場合は充足させるのが最優先
○ 個人レベル：HRT、自主自立、自責利他、責任
感、情熱
○ 相互：相性の良さ、許容範囲
● 成果が次の期待や良好な関係性を作る
○ サイクル
● 成果は目に見えるなにか
○ 状態や変化の認知・解釈、次の行動
● （短期的には）進捗はすべてを癒す
○ 即物的な感じがするけどそういうもの 19
良好な関係性
期待
成果

View Slide

成果に至る構造：遷移
20
成果
良好な関係性
期待
振る舞い心情
施策
分析課題発見
知見
データ

View Slide

SREって言わなくても
力強くやるべきことをやっていれば
自然とSREになることがある
21

View Slide

SRE本の原義との対比
SRE本の定義をざっくり抽出すると
● ソフトウェアエンジニアリングを用いてサービス運用を再定義すること
● それを組織的に強力に支援すること
の2点。
後者にまで自然となるか、というと少しジャンプが必要な場合が多いかな...
後者に踏み込む場合は他社の人事制度・組織運営を参考にするニーズが大きいの
で、SREというキーワードをうまく使うと効果的。
22

View Slide

想定QA
23

View Slide

SREという単語を登場させなかったのはなぜ？
→誤解を避ける、印象論を避ける、自転車置き場の議論を避ける
● ワーディングからくる期待値があったり、要否がわかれたり
● 特に「ワーディングを正確に理解することのプライオリティが低い」ステー
クホルダーには単に負担になり、しかし誤解を招きやすくなる
● キーワードを使って期待値や方向性をすりあわせられるとよいのだけれど
も、実際のところDivercityがテーマになるくらいなので明確な内容や期待値
を表せる言葉ではなくなっているんだと思う
● ほしいのはドリルじゃなくて穴という話に似ている
● SREという考え方やプラクティスは高速道路なので活用したいが、免許練習
中のひとを高速道路に放り込まれても困っちゃうだけ
24

View Slide

どこから手をつけたらよいでしょうか？
最近の鉄板は
● Monitoring
● Performance
● Security
● Developer eXperience（開発環境、CI/CDなど）
だけど、鉄板プラクティスよりも、観察とインタビューを重視したほうがよいと
思います。
25

View Slide

うまくいったのは結局のところ幸運だっただけじゃない？
仰るとおりそうかもしれません。
事例や経験を集めると、幸運じゃなかったときにどうしたらいい感じになるか、
あるいは撤退すべきか、判断材料になっていいなと思います。
みんなシェアして！
26

View Slide

手が回らないんだけど...
【宣伝】
X-Tech 5ではSREaaS（SRE as a Service）をご提供しています。CTOクラスから
エンジニアまで、組織課題・広報・採用・マーケ・エンジニアリングなどなど、
コンサルティング・アドバイザリ・エンジニアリングなど幅広く対応していま
す。
Contact - 株式会社X-Tech 5（株式会社クロステックファイブ）
https://x-tech5.co.jp/contact_form/
※株式会社X-Tech 5はSRENEXT2022のシルバースポンサーです
27

View Slide

非ITの事業会社にSREと言わずにSREを持ち込んだ

非ITの事業会社にSREと言わずにSREを持ち込んだ

Toshiaki Baba

More Decks by Toshiaki Baba

Other Decks in Technology

Featured

Transcript