好奇心の足跡

飽きっぽくすぐ他のことをしてしまうので、忘れないため・形にして頭に残すための備忘録。

SRE Lounge #12 (オンライン開催) イベント参加レポート

2020年5月22日(金)に開催された、SRE Lounge #12 (オンライン開催) に参加しました。というか視聴しました。

sre-lounge.connpass.com

前回 SRE Lounge に参加したのは去年の2月、産休に入る前で #7 でした。イベント参加レポートも書いてた、えらい。

今回は「初のオンライン開催、各社SREの取り組みを紹介」ということで、SRE(というか開発運用)からすっかり離れて1年半近く、最近どうなってるんかなぁ?という思いもあって参加しました。オンライン開催とてもありがたい。

今回も、自分の理解のためのまとめと、ちょいちょい感想、みたいになった。
普段こういうイベントに参加すると、自分のポジションからどう感じたか、どうアクションに活かすか、みたいなことを中心にメモするんだけど、現在休職中。ポジショントークするポジションがないわー!とふと気づくなど。

SRE Loungeとは

SRE Lounge は、サイトの信頼性、エンジニアリング、スケールする分散システムに深い関心を持つエンジニアのための、オープンな集いの場です。

SRE の思想や考え方に興味や関心のある様々な人々と交流し、日々の現場の取り組みや研究成果を伝え、日本のエンジニア界隈を盛り上げることを目的としています。

Facebook グループや、Slackもあるそうです。

Alerting Strategy for Self-contained Team

Quipper Ltd Takeshi Kondo (@chaspy_ ) さん

speakerdeck.com

アラートの話。「アラートは好きですか?」から始まった。
タイトルにもあるSelf-contained = 自己完結化。自分たちで完結した開発できる状態を支えていくのをミッションとしているとのこと。
アラートは基本的にSREが受けて、Developチームにエスカレーションする構図だったが、開発メンバーが増え、SREがボトルネックになる状態を避けたいのもあり、自己完結化を目指すように。

本日のテーマ

  • アラートのレビューは定期的にやりましょう
  • アラートはすべてSLOのためにあるという意識
  • (SREチームも開発チームも)一緒にやりましょう

まず、アラートのレビューについて。1週間くらいかけてアラートを全部見直した。166個あったアターとから、40個を削減。
ポリシーを決め、これに沿って削減。「アクションに繋がること」というポリシーはとても大事と思う。
結構減らせたんだなーという印象。CPUアラートなど重複しがちなアラートがあったので、重複・不要なものを中心に削減していったそう。
アラートは3段階。Emergency, alret, noticeとして、Slackでチャネル分けしている。

次は何をアラート対象にするかの話。CPU使用率が高い場合、直接障害につながるわけではないが、いずれ障害につながる。OOMも然り。だが、こういったメトリクスを追っていくとキリがない。
なので、CPU使用率などのメトリクスベースではなくSLOに注目してアラートを設定する運用にしてみた。まずはSLOを定めて運用してみて、見えてきた運用の仕方。
CPUやOOMなどのメトリクスは、別にダッシュボードで確認できるようにしている。こちらは時系列で終えたほうが良いというのもあり、この運用に落ち着いている。

最後に、アラートの処理とチームいついて。
サービスチームはSLOに関するアラートだけを見るように。アラートの飛ばし方は、然るチャネルに然るアラートを飛ばすという愚直だがシンプルな運用に。この仕組を素早く展開できるようにする方に注力した。

SRE、開発チーム、境界とか引かずに一緒にやっていきましょう。

アラートのレビューについては、大事だとわかっていても中々手がつかず、いざ手を付けてみても家の片付けと一緒で「このアラート本当に消して大丈夫?」みたいになってなかなか手放せず(消せず)。そしてどんどん増える一方のアラート…。ってなりがちなので、サービス運用開始前から定期的に精査すべき。ってのを再度心に刻んだ。

メトリクスベースではなくSLOベースのアラートを、っていうのは「入門監視」にもあったってどなたか呟いていらっしゃったけど、あまり馴染みがなくてとてもためになった。確かにメトリクス系は時系列で状態を判断したいから、アラートで駆動するのではなくてDashboard化して日々のモニタリングでカバーしたほうが良いのかもしれない。これもアラート削除と一緒で、切り替えにはかなり勇気がいりそう。

最後にSREと開発ボーダレスの話。チーム編成の背景やチーム、サービス規模にもとても依存すると思う。もともとほぼ一体化しているようなチーム編成もあるし、かっちり役割もチームも分けている編成もある。けど逆に考えて、ボーダレスとまでは言わなくても、お互い手を出し合える状態が維持できるように、サービス規模が大きくなってもチーム編成やコミュニケーションを工夫できると良いんだろうなぁ。そういう話も聞いてみたいな。

SecurityをSREチームの成果指標に加えた話

eureka, inc. 恩田拓也( takuya_onda_3 ) さん

speakerdeck.com

ということで、セキュリティ×SREの話。
予防・防御や、検知には気が向いていたが、アセットマネジメントで来てますか、とかバケットに何入ってますか、みたいな 非技術分野 なところへのセキュリティの遅れというのが課題だった。今回は、セキュリティチームが出来たときに、SREチームとどう協業して今に至るか、という話。

何をやったか。

  • DevOpsのように、SREチームとセキュリティチームで、部門をまたいで目標を共有
  • タグによるリソース管理・構成の標準化など、安全な選択をデフォルトに
  • 無駄なコミュニケーションが発生しないような、情報を欲している人が自分でPullできる状態にしておく

1つ目のSREチームとセキュリティチームで設定した目標について
アラートに対して、目標収束日数以内に収束できたかどうかのパーセンテージをインジケータとして使用した。脅威度(CVSS)によって対応目標日数を変えて定めている。脅威が高いほど素早く対応すべき。

2つ目の「安全な選択をデフォルトに」について
リソースの管理をタグでする、サービス構成を標準化する、Securityアカウントの集約、など。人的&金銭的コストが高くつく、大変な選択をせずにベスプラを選択できるように導いてくイメージかな。
意識しているつもりだけど、最新のサービスや仕組みにキャッチアップしていかなきゃいけないし、トレンドやベストプラクティスもウォッチしとかなきゃだし、更にそれを標準化して横展開していくとなると、相当の熱量がいる。技術だけじゃなくて人も動かす能力が必要。短い言葉だけど色々詰まってるなー、と聞きながらぼんやり考えてました。でもこういうのがやっていけるエンジニアでありたいなぁ。

3つ目のコミュニケーションの疎結合化は、これも中々気になりつつどうするのが良いかわからないやつ。全体の構成図が揃っていてメンテされている状態を維持するのはとても大変。でもセキュリティの観点からも、そ言ういう情報にアクセスしたいと思った人が、ほいっと見に行ける状態を作っておけるのが理想。この前の #InfraStudy のLtにも同じような話題が出てきた。
これうまくやらないと、もし一度この状態に持っていけたとしても、メンテナンスが人に依存しまくってしまって、いつも気にかけてメンテしてくれる人がある日突然いなくなったら、無法地帯に。長期運用まで考えると正解はどこにあるんだろうなぁ…。

特に「安全な選択をデフォルトに」の章、

  • 持ち物を管理しやすくするために用意されている仕組みを、ちゃんと把握して使うようにする
  • 構成はなるべく標準化して管理・把握・最新化しやすくする

など、開発運用する身として意識したほうが良さそうなトピックが詰まってたな。再度肝に銘じておきたい。

SLI, SLOとカオスエンジニアリング、そしてオブザーバビリティ

New Relic株式会社 大谷 和紀 ( @katzchang ) さん

speakerdeck.com

↓↓NewRelicさんのブログ↓↓から、より良いSREを実践するためのtipsをいくつか紹介。面白そうな記事が沢山!

blog.newrelic.co.jp

ブログの紹介ベースなのでテンポが早くメモが追いつかなかった。面白かったフレーズを。

  • "誰よりも早く障害に気づいたなら、障害はなかったことにしてよいのでは。誰も不利益を被っていない、がっかりしていない。→誰もがっかりしないうちに直そう。"

  • "カオスエンジニアリングは、システムを壊すのが目標ではなく、学んで改善するのが目標。"

  • "SREは燃え尽きに気をつけて。SREはサービスの安定やコストダウンが要求される。コストダウンは最初1/3くらいは楽にできる。そこからがとても厳しい。評価もされなくなる。品質管理を「前倒し」して、設計やユーザー調査など上流段階から踏み込むことで、うまいことできるのでは。"

番外編。大谷さんは記事の翻訳もよくされているらしいのですが…

  • "みんなDeepL使ってる。翻訳のモチベーションが下がるくらい。「DeepL使ってねー」って言いたくなる。"

いつもついつい慣れてるgoogle翻訳を使っちゃうのですが、この際デフォルト翻訳エンジンを変えてみよう。本当は翻訳機能使わなくて大丈夫なくらい英語ができるようになりたいけど…🥺

  • "Pure SREとEmbeded SRE、Pureは中央のSREなイメージ。Embededは書くエンジニアリングチームに入って活動する。"

これは、うちもSRE立ち上げるときに似た思想でやっていました。名前は「Coreメンバーとそれ以外」だったので、PureとEmbededのほうが断トツで格好いいなー。

全体の感想など

初のオンライン開催にも関わらず、とてもスムーズな進行、安定した配信でした。さすがSRE…。QAも質問をポンポン拾っていってポンポン答えていて、テンポ感がとても良かったように思います。

…そう、テンポ感がとても良かった。1年半ほど社会に出ず幼児&乳児と戯れる日々を送っていた私には、皆さんの喋りが1.5倍速に聞こえて、最初配信バグってるんじゃ?と思う程でした…。メモも全然間に合わないし、他の人のつぶやきを見て「ほーう」とか言ってたらもう置いていかれてる…。
前はもうちょっと喰らいついて行けてたと思うんだけどなぁ…( ˘•ω•˘ ).。oஇ
あと1ヶ月ちょいで復職の予定なので、とっても強烈な刺激 & リハビリになりました。ありがとうございました。

あと、SRE Loungeは前もTwitterのTimelineが恐ろしく活発で、「みんな話聞きながら、スライド見ながら、発言をまとめてツイートしてんの?すげーーー!!」って思ってたんですけど、今回も健在でした。でもその雰囲気、リモートでも全然違和感なくすっと馴染んできて、リモートのデメリットは視聴側としては全く感じませんでした。終わった後にお酒飲みながらワイワイが無いくらいかな。

今後もしばらくはオンライン開催を予定しているとのこと。とてもありがたい。