ゆるSRE勉強会第二回に参加した（備忘録）

# ゆるSRE勉強会に参加してきた
[ゆるSRE勉強会](https://yuru-sre.connpass.com/event/293783/)に参加してきました。
簡単にレポをします。

### 簡単な感想
面白い。
一方自分にはSREという共通の話題が無いので懇親会ではちょっと浮き気味だったかも。
雰囲気もとてもよく、みなさんの人徳だなぁという感想が出てきた。

### 書いた人の属性
- 23卒
- 非情報系出身
- SES所属

こんな属性でSREとは業務では全く関係のない自分が感じたこと、まとめたことを書いておきます。

## 「SLO Review」今やるならこうする / If I had to do the "SLO Review" again  
発表者 : [Chaspy](https://twitter.com/chaspy_)さん
- マネージャを上手く使うのが重要
    - 究極、マネージャは「なんとかする人」なので、なんとかして〜って言えると良いよね
- 中央集権と地方自治のラインの見極めは技術、ただ区切りはきちんと線引きしておくと良いよね
- 手段と目的が入れ替わることがままある。
    - SLOを手段として導入してしまっても、最終的に目的意識持って取り組めるようになれば良いよね
- 小さな合意からステップアップを踏んでいくことが大切。
    - 大きな合意は最初からは取れない。
- 信頼性はビジネスに欠かせないが、ビジネスからは何段階か遠い。
    - 相手の信頼を得られるような行動をして、合意の上でSLOができると良いよね
- 誰かが苦しいのは良くなくて、みんなが嬉しいのがやっぱり一番ベスト
- 困った時はコミュニティを頼ろう。困ってるテーマでLTをしたっていい、懇親会で話を聞いたって良い

発表スライドはこれ
[「SLO Review」今やるならこうする / If I had to do the "SLO Review" again](https://speakerdeck.com/chaspy/if-i-had-to-do-the-slo-review-again)

## ポストモーテムの基礎知識と最新事例 / Fundamentals of Postmortem
発表者 : [清水](https://twitter.com/isaoshimizu)さん
- ポストモーテムには二つの意味
    - 検死
    - 失敗した後、なぜ失敗したかを話し合う <- SREの文脈ではこちらの意味
- ポストモーテムを書くときに重要なこと
    - 非難をしないこと
    - 再度同じ問題を起こさせないこと
- 古くは障害報告書等とも呼ばれていたが、今はポストモーテムの方がいい感じ
- ポストモーテムの構成例一部抜粋
    - 対応（その場で何をしたか書く）
    - その他（所感、もうやだねといったエモさがあるようなことを書いたりする）

- 再発防止策のテンプレートを作っておいて、ポストモーテムを書くことを周知しておく
- ポストモーテムの考え方はインフラ以外にも活きる。ビジネス、その他。

発表スライドはこれ
[ポストモーテムの基礎知識と最新事例 / Fundamentals of Postmortem](https://speakerdeck.com/isaoshimizu/fundamentals-of-postmortem)

# SREは生き様だ・リスクの需要について・キラキラしていない話をする
発表者 : [maru](https://twitter.com/maruloop)さん
発表資料はまだインターネットに上がっていなかったので、覚えてる範囲での趣旨をタイトルとしました。

- 勉強会駆動SRE -> SRE,SLOを社内で始める前に、登壇する気構えで準備をしてから始める
- リスクの受容も重要
    - 最近でたSRE本の大半はリスクの受容について記述している。
    - リスクの受容とは、「この程度のサービスレベル低下であれば、対策をしない」ということ
    - 実生活でいえば、小銭が必要な時に小銭がなくても、困る事態が少ないから、小銭を揃えて持ち歩かない、とかになるだろうか。
    - キャッシュの追加等のシステムの施作も、リスクを受容していると考えられる
        - キャッシュを追加するとデータ鮮度が落ち、不整合の可能性が高まってしまう。
- このリスクの受容について、ビジネス側の判断の要素が大きくなってしまうため、登壇資料等には出てこない。
- 例として、maruさんが所属している企業のマイクロサービスの一部で、エラーが出ても通常通りシステムが稼働するようにシステム設計を行っていることを挙げていた。
- サービスデグリゲーション?という考え方の取り入れ（メモの撮り忘れ）

# LT枠
酒が入ってここからメモを取らなくなっていた。

## 組織を作るカンリーSRE
発表者 : 井上さん
株式会社カンリーでのSREチームの発足、責任の分離についての発表

## 設計という共通認識 ~クラウド移行で感じた、疎まれるPR~
発表者 : [鈴木](https://twitter.com/yjszk666)さん
株式会社リブセンスでのシステムクラウド移行の際のPRについての話。
PRが巨大すぎること、説明文が読みづらかったことがあり、PRがスルーされていた。
前提の知識のすり合わせのコストがこの状態では高すぎる現状があった。
marmaid等のGithubのツールを使ってPRをわかりやすくすること、
そして「小さくて可愛いPR」=ちいかわPRを心がけましょう
青森県の公共賭博系のキャラクターが推しとのこと

## TerraformでもSQLスキーマの管理がしたい！
発表者 : [小澤](https://twitter.com/kota65535)さん
SQLのスキーマ管理を宣言的にできる（flywayみたいにALTER文で書かなくていい)ツールを作った話
Flyway,手元で動かす分だけだとALTER文でファイルが何個もできてしまいがち。
ファイルを変更するだけでALTER文自動発行できるツールが既存にもある。

## k6で負荷試験をやってみた話
発表者 : 山田さん
k6 -> javascriptベースでブラウザのアクセスを仮想で実行してくれるシステム
https://k6.io
コードベースでテストを書けるため、使い回しが可能。
Java,GUIベースの童謡の機能よりも高い評価を集めている。

## Kubernetes アップデートのツラミで気付いたデプロイ手順の歪み
発表者 : [逆井](https://twitter.com/k6s4i53rx)さん
Helmとargoのデプロイ参照方法の違いを理由に、ステージング環境のkubernetesの変更でデプロイが不可能になった話。
過去のkubernetesのログを参照しているのに、変更が加えられたため過去のkubernetesが読めずにエラーが発生したとのこと。

# 振り返り
- 良い刺激になった。
- まとめて文章を書く体力がそもそも足りない
- 楽しかった！

#### 懇親会等で得た情報
- markdownベースでスライド資料を作ってくれるmarpなどなどのツールがある。
- SREの根幹は組織の中の信頼、コミュニケーションと相互理解によって成り立つ

終わり！
間違ってたらごめんなさい！
酒で記憶が消えないうちに勢いでアップロードしちゃいます！

今回後援・運営・登壇していただいた方、お話していただいた方、本当にありがとうございました！