【全力土下座案件】JAWS-UG SRE支部#2登壇の件

皆さん、先日のJAWS-UG SRE支部#2はご覧になりましたか？

こんにちは。パネルディスカッションに５分だけ出演した @syou1024です。

いや、、、本当ごめんなさい🙇‍♂️🙇‍♂️🙇‍♂️🙇‍♂️🙇‍♂️

あのタイミングで家の回線が障害を起こしてしまい。。。マンション全体で翌日15時まで回線障害で手を打ちようがなく、突然の退出になってしまいました。。登壇前から声がブツ切れで聞こえておりちゃんと回答できるか不安を持っていたのですが、まさか全断するとは思っておらず。。

ご参加いただいた方々、ここまでご準備いただいた主催者の皆さん、本当に申し訳ないです。そして、途中から急遽登壇してフォローしてくれた @grezarjpありがとう。

せめてもの償いとして、もしあの場にいたらどんなことを答えていたかこのブログでご回答させてください🙏 アーカイブを拝見した上で各テーマ毎に考えたことを以下に書きます。

Question.開発組織とSREの組織の距離って色々あると思うのですが、皆さんのベストな距離感ってありますか？

理想はあれど、ベストはないと思っています。開発組織の状態やシステムのアーキテクチャによって変わると思っていて、タイミングと共に変えるものと思っています。

理想は手塚さんが仰っていたようにAPIやドキュメントを通して会話するだと考えています。AWSのサービスに対する関わりと同じようなイメージで、それより自社の開発チームにとって理解しやすいものになると想像しています。ただこれはあくまで理想型で、開発組織の成熟度によって変わるものと思っています。

開発チームがSREのプラクティスに対して理解が不足する時ほど密接に繋がる必要があるし、理解が進んだら疎にしていく。

また、SREと開発チームの関わりを考えるとき、まずどのような開発チームであるべきか考え、今の開発組織とのギャップによって、どのような関わりをするべきか考えたいです。僕はスモールで自律的な開発チームであることが一番大切と考えてるので、スモールなチームが自律性を保ちながらRelivilityやProductivityを改善できる状態を作れる状態にしたいです。開発チームが既にRelivilityやProductivityを改善し続けられるなら関わりは薄くしますし、そういった取り組みが出来ないなら深く関わりに行きます。

補足. なぜスモールで自律的なチームなのか？

僕はジェフ・ペゾスの２枚のピザ理論だったり、ダンバー数を信じています。チームがパフォーマンスを上げるにはチーム内の信頼関係は必要不可欠だし、信頼関係を気付ける人数は限られています。さらに、チーム内のコミュニケーションに比較し、チーム間のコミュニケーションは多くのコストを要します。なので、出来る限りのことをチーム内でクローズできるようにしたいです。それによって開発のProductivityが上がると考えています。

Question.採用を検討する際にエンジニアに求めるスキルセットやレベル感はどのようにお考えでしょうか？

チーム全体として求められるレベルを達成できれば良いと思うので、全てが出来る必要はないと思っています。

マネーフォワードとしては、コンテナ技術、クラウドインフラ(IaC前提)、コーディング力に加えて、Webサービスの運用経験は見ています。全て必要でなく、いずれかで良いと思っています。(もちろんカバー範囲が大きいほど良いです。)

ただそれ以上に大事だと思ってるのは、リーダーシップです。自分で考え、ステークホルダーを巻き込み説明責任を果たしつつ、その決定に対するリスクをちゃんと自分で負って、実行を進められる人。

どんなポジションであれ、リーダーシップは必要だと思ってるのですが、SREは自分以外の開発組織を変える役割を担ってると思っているので、どんなに技術力があってもその技術を通してシステムや開発組織を変革できない人では不足を感じます。

amazonさんの全員がリーダーと言うポリシーにはめっちゃ共感しています。僕のチームにはそれを求めてます。

Question. 開発の人がSREに興味を持つにはどういった動機づけがいいんだろう🤔開発の人に権限移譲したいが、そもそも意識改革が必要なのが悩ましい。

まずは開発者フォーカスするのが良いかなと思いました。

マネーフォワードは権限移譲を進めようと思っていますが、権限移譲は手段です。これ自体は目的ではありません。なぜ権限移譲が必要なのかと言うと、それは開発チームのProductivityを上げたいからです。権限移譲を進めない方が良い会社やフェーズもあると思うので、目的に立ち返って欲しいです。

権限移譲の目的がProductivityの向上なら、Productivityを上げたくない開発チームなんていないと思います。まずは4keysなどを用いてProductivityを可視化し、一緒にProductivityを上げるためにはどうしたら良いか考えて、手段を探ったらどうかと思いました。その結果、自分達で権限を持った方が良いと思ってくれたら、権限移譲が進むのでないでしょうか。

Question. SREチームがまだ社内に存在しない我が社です。〜(略)〜「こんなフェーズになったらSREチームを組んだ」「こんな現象が起きたらSREあった方がいいよ」など閾値的なものはありますか？

ここは言いたいことは登壇者の皆さんが話されてたので、特にないです。

Question. AWSの場合、とにかく最後はLambdaでなんとかするって言うのが多いと思うんですけど、Toilの撲滅の意味で作って費用対効果高かったLambdaランキング

牧田が言ってる通り、マネーフォワードとしても、ほぼ使っていないです。ここも言いたいことは登壇者の皆さんが話されてたので、特にないです。

Question. SREとしてセキュリティに対してどういう役割を担っているのか。セキュリティ面で特に重宝してるAWSサービスを１つだけ挙げるとしたら何か。

セキュリティを開発者の人たちが出来る限り意識しないようにガードレールを引くのが大事だと思っています。ベースのセキュリティを守れてる状態を作りたい。

マネーフォワードだと、アカウント作成時に自動プロビジョニングしてアカウントに制限を入れたりしています。

通信のロギング
リソースのロギング
IAM権限の制限

など。

モニタリング/ロギングの観点でAWSのコンポーネントで利用するサービスなどの事例があれば教えてください！

マネーフォワードとしてはほぼモニタリングでAWSは使っていないです。 Datadogに集約を進めています。

AWSの特有のマネージドサービスは積極利用しません。

絶対使わないわけじゃないのですが、実は極力AWS独自のマネージドサービスには寄せないようにしてたりします。

ECSよりEKS
CloudwatchよりDatadog
KinesissよりMSK(kafkaマネージド)
Cloudformationよりterraform

を選択します。

以下のようなモチベーションでAWSのレイヤーをOSSで抽象化をしたいです

オンプレ環境が存在していて、同じ技術スタックを利用したい。
よりデファクトスタンダードな技術に注力したい。　人材採用、エンジニアが身につけたいと思う技術にしたい
自分のコントロールの配下に置いておきたい。
将来の成長した時の移行性　ベンダーロックに気をつけてるところがあります。将来マネーフォワードがもっと成長した時に本当にAWSを使い続けるのだろうかと考えています。ある程度の大きさになると自社にエンジニアチームを持って、PrivateCloudを構築した方がコスパが良いと思っていて、その可能性を踏まえて移行しやすくしたい。

繰り返しになりますが、AWS特有のマネージドサービスを絶対使わないわけではないです。そのマネージドサービスの恩恵や代替手段を取るために課せられる運用コスト、それとマネージドサービスを利用した際の将来の制約、将来のビジネス的な戦略などから自分達にとってちょうどいいバランスを取りたいと考えています。