インフラ民主化でトイルを1/9にした話 - Link and Motivation Developers' Blog

こんにちは、Motivation Cloud(以下、MC)のSREをしている岸本です。

今回、最近取り組んでいるインフラ民主化の内容の一部を紹介させていただきます。（前提、弊社はAWSを用いております）

インフラ民主化とは？
背景
概要
詳細
今後の展望

インフラ民主化とは？

我々SREはFour Keysを基準として自律した生産性の高い開発組織をハイパフォーマーにしていくことを目指しています。
ハイパフォーマーにするために、改善活動に注力していきたい一方、プロダクトが増え、開発者からの依頼等で改善活動に充てる時間が減ってきていました。
さらにSREが繁忙期の時、簡単な依頼でも、その依頼をしてから完了するまでのリードタイムが伸びてしまい、開発体験を損なわれていく恐れがありました。
なので、インフラ面で開発者ができるところは、開発者自身が行い、
SREは開発組織の生産性向上の改善活動に多く時間割いていき、
開発者と一緒にハイパフォーマーな組織を目指すことを指しております。

背景

現在、3人でMCのSRE(以下、MC SRE)として改善活動しているのですが、改善活動にどのくらい時間を避けているのかを分析したところ、
月の平均約40％ほどしか、改善活動に注力できてませんでした。改善活動ではない活動(以下、トイル)の中で、
対応時間が長い、トップ３を以下にまとめます。

トイル	対応平均時間/月
開発者からの依頼	35h/月
顧客からのセキュリティ要件の確認事項	25h/月
環境のミドルウェアアップデート	34h/月

この時間を削減をすることで、改善活動に割り当てられる時間を増やすことが可能です。

概要

すぐに変えられるものとして、開発者からの依頼の時間の削減をしました。
開発者からの依頼がどのようなものがあるか調査したところ、依頼回数が多く、たくさんの時間を割いているのが、主に３つあることがわかりました。

テスト環境の構築・削除
テストデータの新規作成・洗い替え
本番環境のS3のデータ更新

上記３つを開発者が自分でできるように、自動化することで、SREの対応作業時間が削減され、かつ、開発者も依頼から、完了までのリードタイムが自らの予定に組み込めることが可能になり、win-winな状態を目指すことにしました。
そのために、いくつか自分が行ったことを以下の詳細に記載します。

詳細

本番と開発AWSアカウントの分離

本番環境と開発環境のAWSアカウントが分かれていなかったため、まずアカウントの分離をしました。
一般的に用いられる、踏み台のアカウントから各アカウントにスイッチロールする運用にしました。

ロールの運用について

各アカウントにスイッチロールする権限を以下のように設定しました。

開発アカウントについて

基本的に、開発用なので、自由な作業ができるようにAdmin権限を与えています。

ロール名	内容
lm-console-users	Admin権限

本番アカウントについて

二つのロールを用意し、本番作業以外の時は、基本的にRead Onlyの権限でスイッチロールする運用にしております。

ロール名	内容
lm-console-users	Read Only権限
lm-root-users	Admin権限

開発者にS3のファイル更新やリリース等の本番作業をできるところから所から委譲していきたいため、
Admin権限にスイッチロールできる運用にしていますが、開発者が何の操作をするか監視ができ、誤操作を起こさないために、
Admin権限へスイッチロール時、Slackに通知するように設定しました。
将来的には承認がされないとスイッチロールできないようにしていくつもりです。

開発者が自由、かつ、簡単に開発環境を作成できるためのツール作成

開発アカウントで、テスト環境構築や、テストデータの作成等のインフラ運用をアプリ開発者単独で行えるように Codebuild 自動化を行いました。
例えば、次の様な (これまで SRE が都度依頼されて行っていた) インフラ運用を CodeBuild にし、パラメータを指定する事でアプリ開発者個々の環境に合わせて簡単に環境構築が出来る様になりました。

インフラ運用	実現方法概要
環境構築	AWS CDK での構築の自動化 lambdaの作成の自動化 EC2サーバーの作成の自動化
開発データの新規作成・洗い替え	RDS へ dump ファイルの投入をします
デプロイ	変数指定した Git branch コードを、Amazon ECS へデプロイします

インフラ民主化の文化浸透の活動

例え素晴らしいものを作ったとして、今までと運用が変わる場合、
開発者が頭で納得したとしても、行動はなかなか変えられず、結果的に全く使ってくれないなど、文化の浸透はかなり難しいものです。

今回、文化の浸透で重要だった２点を以下にまとめます。

1. 意識の変革の設計

まず、初めにやらないければいけないことは開発者の意識の改革です。
現状開発者はどのような考えでいるのか？
また、その考えをどのように変革していかないといけないか？
その設計を最初にしないと、文化の浸透はできません。

今回、新しい運用に変更するにあたって、開発者の考えを
インフラ系はSREに頼まないといけないもの、SREがやるもの
から
自分たちでやっていこう、インフラも理解していこう
というような意識の改革が必要でした。
そのために、目指したい開発組織の未来について説明会、インフラを学ぶメリット、勉強会・デモの実施を行いました。

2. 協力者の創出

開発者の人数が多くなればなるほど、文化の浸透は難しく、
例え説明やデモを全体の場でやったとしても、運用には乗りません。
そこで文化の浸透をするために、各チームで協力者を募りました。
その協力者に対して、目指したい開発組織の未来について説明会、インフラを学ぶメリット、勉強会・デモの実施を継続して続け、 SREの目指している世界観を理解してもらい、インフラ民主化の協力者となってくれました。