関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1M
各ページのテキスト
Enablingについに成功した話
おまえ誰？ ● 千株式会社のソフトウェアエンジニア 同じビルの14Fから来ました 昔はSREをしていたが、膝に矢を受け…… いまはバックエンドエンジニア？ ○ ○ ○ ● 好きなもの archlinux neovim ○ ○ ● 趣味 バイク 楽器 自宅サーバ・自宅kubernetesクラスタ ○ ○ ○ ● 犬派
今日話すこと ● ● ● ● なぜEnablingが必要になったか インフラ・SRE経験者が不在のチームに対してEnablingを実施した話 まとめ おまけの話
ことのおこり ● ● ● ● はいチーズ! はだいたい20年近くサービスを提供しています。 サービスを長く継続していると、ユーザに価値や利益を提供する一方で、 社内の業務や安定運用をつらくしていく、価値を生み出す黄金の技術負債が ところどころに発生してきます。 これに立ち向かうべく、ドメインごとにサービス・データを分割しています 合わせて、チームもドメインごとに再編成されています
整理された組織構造と、その課題(公開版) プロダクトチーム複数に対して、SREsは組織横断チーム1つのみであることで、 以下の問題が生じていた 1. 横断SREsにすべてが集中するので負荷集中・ボトルネックになる 2. プロダクトチーム・エンジニアに信頼性にまつわる知見が蓄積しづらい 3. プロダクトに合わせた信頼性の担保が難しい これを解消したいため、各プロダクトチームのEnablingを実施せねば
よし、やるぞ！
チームの課題感 ● チームのビジネス上の状態 ○ ○ ○ ● 既存機能から切り出して新規サービスとしてリニューアルスタートしたい やっていけるのか？ も含めて早期に判断するため、早く出したい 一方で、toBサービスなので、サービスの品質・安定性を理由に解約が発生するリスクは 可能な限り下げたいので、スタート時点から信頼性回りにもテコ入れしたい チーム構成の状態 ○ ○ エンジニアリングマネージャー、プロダクトマネージャー、バックエンド2名、フロント1名 信頼性回りもインフラ回りもやったことがないので、ちょっと不安がある
まさに 1. 横断SREsにすべてが集中するので負荷集中・ボトルネックになる 2. プロダクトチーム・エンジニアに信頼性にまつわる知見が蓄積しづらい 3. プロダクトに合わせた信頼性の担保が難しい
どうやったのか
学習の4段階 1. 2. 3. 4. 無意識的無能（知らないからできない） 意識的無能（わかっているけどできない） 意識的有能（意識するときだけできる） 無意識的有能（意識しなくてもできる）
1: 知らないからできない ● プロダクトチームのつらい業務にアプローチする ○ ○ たとえば: ■ CPUアラートを見て手動でスケールしている → オートスケールっていうのがあるよ ■ 開発中だから、と言って手動でデプロイしている → CI/CDっていうのがあるよ ■ アラート大量でつらい → ログベースだけじゃなくて、SLI/SLOっていうのもあるよ ■ 本番と開発環境で差異がある → IaCを使うといいよ ■ etc できたら一緒に改善する
2: わかっているけどできない ● とにかくやってもらうしかない！ a. ● わかっているけどできないには2種類ある a. b. ● ● けどやれないのでこの段階 やり方がわからない やるのが怖い a についてはワークショップやハンズオン、輪読会で指針を示す b についてはガードレールを設計する、失敗を許容する
3: 意識するときだけできる ● Slackに #pick-you-are-sre というチャンネルを作った ○ ○ :sre-jan: という絵文字をつけた発言が集約される ■ お、それってSRE的な視点じゃね？ :sre-jan: ■ それ、SRE的なアクションじゃん！ :sre-jan: 変則的なWin Sessionみたいなものかもしれない
まとめ 1. 無意識的無能（知らないからできない） a. 業務のペインと絡めてプラクティスの存在を伝える 2. 意識的無能（わかっているけどできない） a. b. ワークショップやハンズオンでできるまで併走する ガードレールを用意することで足踏みさせない 3. 意識的有能（意識するときだけできる） a. おっ、それってSREやってんねえ！ と伝えて意識を向けさせる
感謝 ● スライドに表示されていたアイコンはこちらを利用させていただきました ○ https://github.com/yuyarin/presentation_icons