カヤック×primeNumber×クラシコム合同SRE勉強会を開催しました

カヤックSREチームの今です。

5/14(金)に3社合同のSRE勉強会をオンライン開催しました。
参加企業は、カヤック、クラシコム様、primeNumber様です。

SREはまだまだ一般的ではなく、知見の少ない役職です。また企業内での人数も少ないこともあり、普段同じ技術領域について話す人があまりいません。
そこで今回のSRE勉強会は、企業の垣根を越えた知見の共有と同役職者同士の親睦を深めよう、という趣旨で開催されました。

その発表資料と一部を抜粋してご紹介します。

GitHub Actionsに「強い」AWSの権限を渡したい (カヤック 藤原

speakerdeck.com

terraform applyなどの強い権限を必要とする操作をGitHub Actions等で継続的に実行するためには強い権限をもたせる必要がありますが、セキュリティ上の懸念点も増えることになります。 そこで、強い権限を一時的に渡すため考えた2通りのアプローチを紹介しました。

デプロイ頻度を高めるための自動化と、権限の強いアカウントのクレデンシャルの保護はサービスの信頼に繋がるものなので、悩みの種なのは各社同じなようでした。
GitHub Actionsは便利になる機能が続々リリースされているので、これからの新機能の動向も気になります。

trocco SREチームの概要と取り組みについて(primeNumber 百々さん

speakerdeck.com

primeNumberで運用しているデータ統合自動化SaaS「trocco」では数多くのデータソースをサポートしており、その特徴から障害の原因も多岐にわたります。 その中、安定して稼働させるためにSREチームが行っている内容を紹介していただきました。

モニタリングやダッシュボードの強化から始まり、エンジニアリングチームを越えてCSチームや営業チームまで幅広く関わって安定稼働のための活動をしているとのことでした。 チームを横断しての活動は座組を組むことが難しいことが多いのですが、しっかり連携して安定性・ユーザーの満足度の向上のための活動が出来ているのが流石でした。

SLI/SLOに関する雑多な悩み(カヤック 池田

f:id:tkonsoy:20210525174729p:plain
(スライド非公開)

SREチームの活動指標となるSLI/SLOの設定について、カヤックで運営している大会運営サービス「Tonamel」で起きた困り事について紹介しました。
本当にユーザーから見える可用性は計測が難しいのでサーバーのメトリクスをSLIとして利用しますが、サービスの種類によってはメトリクスから算出するものが困難であったり、例としてGraphQLはエラー時に200を返すのでエラーレートをSLIとして扱うのが難しい、などの問題に直面しました。
SLI/SLO設定の難しさとは長い付き合いになりそうです、積極的に会社を越えて知見を共有していきたい話題でした。

北欧、暮らしの道具店のAWSマルチアカウント運用(クラシコム 佐々木さん)

speakerdeck.com

開発の"歴史"により1VPCに本番・ステージング・テスト環境が混在したり、アカウントに過剰な権限が付与されている状態から整理して、マルチアカウントで適切な権限、環境の小分けをしてわかった利点、また苦労したことについて発表していただきました。
発祥不明なリソースが本番環境のすぐ側にあった、などの経験は多くのインフラエンジニアが体験していると思います。確認の手間が増えたり、事故の原因にもなるので恐ろしいですよね。

細かくなったIAMロールが増えて管理が大変になる問題には、AWSコンソールではWeb拡張のAWS Extend Switch Roles、aws-cliにはaws-vaultを利用することで管理を楽にできるとのことです。
aws-vaultは今回初めて知ったのですが、シークレットを.aws/credentialsに平文で書かずOSのkeychainに保存できるのが気持ち的に楽なのでいいなぁとなりました。


発表後には懇親会も開催されました。
おすすめのお酒の話から、発表内容についてもう少し深堀りした内容を話したり、最近行われた弊社の新卒研修についての話をしてみたりした気がします(記憶がない)。
SRE Nextなどの大きいイベントはありましたが、SREとして集まって少人数でより深く話せる会は貴重な時間でした。

f:id:tkonsoy:20210525174831p:plain
記念写真(スクショ)

AWSアカウントの管理、SLI/SLOの設定についてのあるある話に花を咲かせた初回でした。
また次回の勉強会も企画中なので、また面白い話(あるいはつらかった話)が聞けるのを楽しみにしています。

カヤックでは合同勉強会を開催していただける会社さんを募集しております。興味がありましたら、カヤックお問い合わせフォームまで是非ご連絡ください。
まだまだ業界を通して知見が浅いSREという役職ですが、お互いのサービスをより良くするための情報共有ができると嬉しいです。

また、一緒にお仕事をする仲間も随時募集しています!
https://www.kayac.com/recruit/career

以上、カヤックSREチームの今でした。

新卒 2 年目でサーバチームのリーダーをやってみて「スーパーマンはいない」と気づいた話

f:id:mk9071:20210514170309j:plain
(Generated by a product, author Irie Shinnosuke)

こんにちは!技術部ゲーム事業部サーバサイドエンジニアの宮村 紅葉です。

社内では「みやむー」と呼ばれています!

普段はぼくらの甲子園!ポケットのサーバサイドエンジニアとして Perl5 を用いた運用・開発のお仕事をしています。

突然やってきたサーバーチームリーダーへの打診!

新卒 2 年目の昨年 12 月に所属チームのプロデューサーに「みやむーリーダーやってみない?」と言われ、2021 年 1 月からサーバチームのリーダーになりました。

この記事では後学のために、リーダーになって数ヶ月の間に経験した、どったんばったん大騒ぎと、若手がリーダーを経験することで何が得られたのかということについて書いてみたいと思います。

どったんばったん大騒ぎ!したこと

自分よりもベテランエンジニアばかり!

「ぼくらの甲子園!ポケット」チームには昨年 5 月ごろにジョインしたのですが、チームのサーバエンジニアは数年以上のベテランの方ばかりでした。

また、プロジェクト自体が運用 6 周年(開発期間も含めるともっと)の長寿タイトルでサーバサイドは歴史的経緯により、運用・開発難易度が高い状況です。

なので「自分が一番プロジェクトについて技術的に詳しくない」かつ「他職能メンバーから判断を求められる」という状況によく直面しました。

幸いにもプロジェクトメンバーや先輩が皆優しい方ばかりなので、時間もらって技術的アドバイスいただいたり、前リーダーを中心にちょくちょく対応の相談をすることで乗り越えられたかなと思います。

普段からチームメンバーと相談しやすい関係性を築いておくことの重要性を感じました。

f:id:mk9071:20210514170124j:plain

他職能から相談される機会が増え、開発に集中する時間を割くのが難しくなった!

リーダーになって、他職能がサーバーに関する相談があった場合、真っ先に僕のところに飛んでくるようになりました。

前述したプロジェクト経験・エンジニア経験の浅さも相まって、それらの対応で 1 日が終わる日もあったり(苦笑)。

リーダー当初は「エンジニアなのにコード一切書けてない・・・!」となり仕事のモチベーション低下や焦りに繋がったりすることもありました。

この点はまだ課題にしているところでもありますが、全部自分でやらずに出来るだけメンバーに委譲したり、Slack のメンションを減らすように工夫したりという取り組みを意識することで軽減されたかなと思います。

例えば、メンバーのリソース状況把握して空いてそうな人にお願いしたり、Slack のメンションは緊急性が高くなければ即レスせずに今のタスクが終わってから返すようにしていました。

前述したように技術的な知見は他チームメンバーが持っていることが多いので、自分はテックリード的な役割よりも、マネジメント的な役割をより意識して立ち回ることで抱え込んでしまうことが減ったようにと思います。

その結果、最近ではリーダー業の合間に Devel::NYTProfDBIx::QueryLog を使った巨大 API のパフォーマンスチューニングをしてみたりと開発に割く時間も増やせてきたように思います。

また仕事でコードを書く時間が減っていたので、プライベートでコードを書く時間を増やし、自分自身の腕をあげることでスループットを上げるよう意識するようにもなりました。

具体的には、リーダーとしてタスク量コントロールして残業を減らしつつ、浮いた時間で所属しているエンジニアコミュニティの活動に積極的に参加してコードを書く時間を増やすなどしていました。

それにより仕事のモチベーションを上げつつ、得られた知見を仕事に活かす、という循環も生まれたように思います。

f:id:mk9071:20210514170116j:plain

一人でなんでも解決しようとしすぎた!

プロジェクトにジョインしてから僕と同時期に入った新卒に色々教えていたので引き続きサポートしつつ、更に新規にジョインしてくれたメンバーに対してサポートをしていました。新卒の子が自分が学んだことを積極的に新規メンバーに伝授するなど、チームとしていい流れを生み出せたように思います。

一方でベテランの方がチームから離れることもあり、その対応に追われたりもしていました。運用歴の長くなってくるとベテランの方が抜けるインパクトは大きいので、その人が担っていた色々な役割を自分が巻き取ったりチームメンバーにお願いしたり立ち回っていました。

このようにチームのリソース状況が大きく変化する中で、企画側の要求に対応していくのが大変で、疲弊してしまっている時期もありました。各方面に相談していくなかでこれはサーバチームだけで考えることじゃないということに気づき、PM (プロジェクトマネージャー) などの他職能を巻き込んで優先度とマイルストーンを定めてもらうことで解決しました。

「スケジュールやリソースで困ったら PM に相談する」という当たり前といえば当たり前の話ですが、リーダーをやる前は無意識のうちに同じ職能である「サーバチームの中」で何とかすることに意識が向いていたなと気づきました。リーダーになってからは積極的に他の職能を頼るという意識が芽生え、視野が広がったなと思います。

一人で抱え込まないことの必要性は頭では分かってたつもりだったんですが、無意識のうちにハマっていました。

まさに「仲間に助けてもらう勇気を持て」ですね!

f:id:mk9071:20210514172209j:plain
オフィス近くの通路

やってみて気づいたこと

リーダー経験はリーダーじゃない時にこそ最も役立つ

こういう経験をしてみて気づいたこととして「リーダー経験はリーダーじゃない時にこそ最も役立つ」ということがあります。

リーダーやる前は、自分の上司や先輩やチームリーダーに対してどこか「スーパーマン的期待」というか、何でも知っているはず、という期待をしていたように思います。でも実際に自分がそういう立場になってみて、そんな幻想はないし 「スーパーマンはいなくて」 、みんな分からないなりにもがいてなんとかやっているんだなぁと気づきました。

そういう目線に立てたからこそ、自発的に動いてくれるチームメンバーがとてもありがたいなとも思い、逆に自分が誰かのリーダーの下で働く立場になったら、リーダーが何に困っているのかを察して先んじて行動しようと思えるようになりました。

リーダーシップはリーダーじゃなくても発揮できるという話にも通じますね。

若手のうちにこういう視点を得られたのはいい経験だったなと思います。

f:id:mk9071:20210514170304j:plain

まとめ

新卒 2 年目でサーバーチームのリーダーになったという経験と、そこから得られたものについて書きました。

「自分は若手だしチームメンバーの方がベテランなのにリーダーやる意味あるのかな?」という疑問を持つ時期もありましたが、実際にやってみると、あえて若手のうちにリーダーやってみることで学べることもあると理解しました。

この記事が同じような境遇の若手リーダー、もしくは若手にリーダー任せてみようかと思っているマネージャーさんの参考となれば幸いです。

カヤックでは若手から活躍したい新卒エンジニアも募集しています

中途採用も募集しています