2020」に参加してきました。学びが多かったので忘れないうちにメモしておきます。参加したセッション参加したセッションのメモをベタ書き。スライドが公開されているセッションであれば、スライドのリンクも貼っておきます。発表資料はさっそくQiitaにまとめている方がいました。マネージャ主導ではなく自己管理型のチームを目指している大規模なPaaS基盤を運用しているSREチームのお話。数あるVMのメトリクス異常だけで通知を飛ばしているとキリがないので、「ユーザ影響のある事象に限り急いで通知→対応する」という方針は良いなと感じました。機能担当者の把握、SRE外と連携しての対応ドメイン知識やコミュニケーションの習得が課題になりがちペアオペレーションとしてオンコール当番の対応を一緒にやるオンコール対応のシャドウイング(実際の障害事例で慣れる)実作業がイメージができる状態にして心理的負担を下げたオンボーディング専用Slackチャンネルを作ったノイズが少ない&質問しやすいメンター以外でもサポートしやすい振り返りに使いやすい入社後のフォローアップ、技術知識なら個人でもある程度は拾っていけますが、ドメイン知識(業務知識)や組織面の把握って確かに難しいですよね。OJTに近い形で依頼タスクや障害対応に触れられると早く身につけられそうです。DSSに準拠させながらいかに運用負荷を下げるか、というお話でした。DSSはパズルゲーム」という名言も登場。個人的には一番印象に残ったセッションでした。振り返りにはKPTを採用Tryの中で最重要項目を1つ決めて、次のサイクルで確実に実施するPairsのSREチーム、組織や運用方針よりの話が多めでした。SREは事業貢献の面での成果が見えづらい、というのはあるあるな気がしています。信頼性向上に限らず、価値提供のスピードアップを支援するなどのミッションを定めて合意しておくことは確かに重要かもと感じました。Frameworkに目を通すクラウド側のセキュリティサービスを活用するSREが担当する領域の広さを再認識したセッションでした。設計段階からセキュリティを考慮し、問題が発見しやすい・対処しやすい・追いやすい環境を作ることが大事ですね。あとはクラウドの機能も揃ってきているので上手く活用しましょうと。可用性99.9%=100%が達成できなかった、という意味ではない。残りの0.1%は改善や機能リリースなどに使える「予算」となり、0.1%のダウンタイムを活用して積極的な変更も可能となる。2020SREの原則について、用語だけでなく具体例も交えて復習することができました。人はミスをする・システムは落ちる、といった前提を踏まえて仕組みを整えていくことが大事ですね。仕組みの作り込みはまさにソフトウェアエンジニアであって、インフラエンジニアとは別であることも実感。有料カンファレンスで人数上限もあったためか、混みすぎることもなくゆっくり過ごせました。休憩部屋・電源・Wi-Fiもしっかりと整えられており運営もスムーズで、ストレスなくセッションや交流に参加できたのも良かったです。各社のSREチームが取り組んでいる工夫や、SREについての考え方も学び直すことができて非常に有意義なカンファレンスでした。SRE本をベースとした発表が多かったため、書籍版を最近買ったSRE本をきちんと読んでみようと思います。運営に携わった皆さん、発表された皆さん、会場でお話してくださった皆さん、ありがとうございました。Message」「LIFF」...2018-12-312018年の振り返りと2019年の目標について2018年の振り返りと2019年の目標について。はてなブログProインフラエンジニアですが、アプリやセキュリティにも手を出しています。適した条件を考えてみた。行ってきた当ブログについてプライバシーポリシーおよび免責事項お問い合わせフォームスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。