note株式会社で技術広報をしているmegayaです。

ゆるSRE勉強会 #8がnote placeにて開催されました。この記事では、当日のレポを簡単にまとめて紹介します。

ゆるSREの運営メンバーと会場の準備をしていたら、発注ミスで水が10リットル届いて笑いました。（本当は500mlを頼む予定だったとのこと）

当日の登壇内容まとめ

Bytebaseを導入した話(仮) / 田中 章悟 - note

まずは弊社のスポンサーLTからスタート。 

複雑だったDBアクセスを改善するためBytebaseを導入した話を、SREチームの田中さんがしました。

導入する前にPoCを実施し、エンジニアに使用感のアンケートを実施。現場での使い勝手に一定の評価が得られたことで、導入に至りました。「とりあえずやってみる！」も大事だけれど、他チームの意見をきちんと取り入れてくれるのはありがたい進め方。

Bytebaseで効率化や柔軟性の向上を見込めたのは大きい。今後はSlackで承認などのフローが完結できるようにしていくとのこと。楽しみ。

▲Bytebaseの基本的な使い方などは上記の記事でも公開しています。こちらもぜひ

組織的にSREが始まる中で意識したこと / abe - IVRy

これまで3名だったSREチームが6名に増えたことで、ローテーションを組めるようになり、役割が変化していく段階になってきたとのこと。

「組織やシステムの歴史を学ぶことが信頼構築につながる」という考え方や、ストーリーテリングを活用して知見を共有する姿勢も興味深かったです。技術力だけではなく、プロダクトへの理解が深いことも重要だなと改めて実感しました。

IVRyの文化でいいなと思ったのは、「文章に残すメンバーが多い」という点。障害が起きたときやバグ対応したとき、ナレッジにしておかないと「前回どうやって解決したんだっけ？」ということになりがち。共有する文化があることは大きな強みだと感じました。

これからSERチームを拡大していく段階の方には、かなり参考になる発表だったのでは。

コンテナイメージを複数のチームで扱うための、ビルドフローの構築・運用 / 小西達大 - コドモン

マイクロサービスごとにチームが存在し、それぞれがコードとインフラを担当する運用体制。そこから、メインサーバをEC2からECSへの移行が進んだときに、コンテナイメージの担保をどう扱うのかという話。

脆弱性スキャンをCICDに組み込むことで、ビルドしたコンテナイメージに潜む問題を早期に発見し、本番環境にリスクを持ち込まない仕組みが整備されているそう。Amazon Inspectorが便利そうで、脆弱性が検知された場合にはデプロイを停止するフローを構築しているとのこと。

LT内でも話題にあがっていましたが、ルールづくりが難しそうだなと感じました。「緊急でバグ対応したいときどうする？」とか、「どこまで厳しくチェックする？」とかはプロダクトによってだいぶ変わってきそうです。

「問題を早期に取り除く」という考えは、ユーザー側からしても安心してサービスを使える素晴らしい姿勢だなと思いました。

▲12/5に「SREのリアル」というイベントを開催予定

ポストモーテムレビューをブレームレスに運営し有効な改善アクションを引き出すために必要だったこと / 山口隆史さん - SMS

インシデント発生後にレビューを行い、状況に対する共通の理解を構築するためのポストモーテムについての話。障害などを個人に留めるのではなく、組織のプロセスや仕組みとして焦点を当てることの重要性が理解できました。

おもしろかったのが、「なぜなぜ分析を進める中で個人にフォーカスしてしまうと、真の原因にたどり着かず、表面的な対応で終わってしまうリスクがある」という点です。身に覚えがあり、たしかにな〜と目からウロコでした。

作業起因のインシデントであれば、「なぜその作業が必要だったのか」「どのような仕組みがあれば防げたのか」を深掘りし、プロセス全体の改善策を考えていく必要があります。

ポストモーテムの実践は、チーム全体の信頼を強化し、再発防止に向けたより本質的な対応を可能にするのだと実感できました。個人ではなく、仕組みやプロセスを見直す視点を持つことで、チーム全体の成長を支える土台を構築していくことが大切なんだなと勉強になりました。

そろそろOn-Callの通知音について考えてみよう (PagerDuty編) / 髙塚広貴 - primeNumber

On-Callの通知音について、PagerDutyの効果音について採点していくというLT。「今日いちばんゆるいLTを目指します」という宣言のとおり、通知音を聴きながら採点の総評を全員で聴くのはシュールな光景でした 笑。

内容は笑えておもしろかったのですが、通知音の選び方も奥が深いものだなと思いました。（私は考えたことがなかったので）

1. 気づきやすさ：音が大事なタイミングで確実に届くかどうか。

2. 公共性：公共の場で鳴っても大丈夫か。迷惑にならない音か。

3. 不快度：聞いていて嫌な感じがしないか。

上記を考えてみると、本当に適した音って選択肢として意外と限られてくるのかなって。

sre初心者が「sreはじめよう」を読んだ感想 / ぴささん

ゆるSRE会らしいゆるいLTでした。私も途中で諦めた技術書が山のようにあるのでかなり共感できました…！

『Becoming SRE』の日本語版は、これからSREを始める人にとっての「最初の一歩」になるような内容が詰まっているとのこと。「SREにコーディング能力は必要か？」というテーマが興味深く、たしかにコードを理解しているかどうかで問題解決のスピードがまったく変わってくるだろうなと。

勉強会やイベントは運営を続けていくとハードルがどんどんあがってきて、登壇するのが難しくなってしまうので、いろんなLTが許容されるゆるSREは良い会だな〜と発表を聞いてて実感しました。

そのライブラリ、続投？それとも解雇？「stay_or_go」で素早く決断！ . / 今 佑介 - UZUMAKI

個人的にすごく興味が惹かれる内容でした。リポジトリ内のライブラリなどを評価して、スコアリングしてくれる自作ツール『stay_or_go』の紹介。

「なんでこのライブラリ使ってるんだっけ？」「気づいたらメンテされてない…！」ってなりがちな部分を定量的に図れるのは良いですね。結果をマークダウンやCSV形式で出力できるのもうれしい点。

• 100以上のライブラリをわずか数分でスコアリング

• 非効率なライブラリを約10%削減

  • 高パフォーマンスなgemに置き換え

  • コードベースのパフォーマンスとセキュリティを向上させる

• スコアという明確な指標ができたことで、運用が楽になった

など、すでに運用実績もあるため、1回とりあえず試しに使ってみるのはありかもなと思いました。

散らばったトレースを繋げる技術 / 巨畠和樹 - Wantendly

トレースがつながらない理由として、Trace IDのフォーマットが異なることや、異なるトレースコンテキスト（LTではOpenCensusとddtraceを例にして）を使用していたことが挙げられていました。これにより、リクエストの流れが途切れ、トラブルシューティングが困難になるケースがあるそうです。

「トレースコンテキスト」が特に重要なのだなと。トレースが途切れる場合には、コンテキストが正しく引き継がれているかを確認する必要がありそう。トレースがつながらない場合、トレースIDやコンテキストの中身を確認し、何が変化しているのかを検証していく必要がある。

これらは知識として認識しておかないと、「繋がらなくなったときに原因が特定できい」などの状況になってしまうことが全然ありそう。

次回、開催もお楽しみに

ゆるSREの方針として、「様々な企業のオフィスで開催する」という指針でやっているそうです。

今回は弊社がnote placeをお貸ししましたが、ゆるSREの運営メンバーの方々は対応も丁寧で安心できるので、「イベントスペースを貸し出せるよ」という方はぜひ運営までご連絡いただければと思います。　

▼note社の技術記事が読みたい方はこちら