SREの仕事とは - Speaker Deck

Slide 1

Slide 1 text

Slide 2

Slide 2 text

©2024 Metaps Holdings, Inc. 社名  株式会社メタップスホールディングス   (Metaps Holdings, Inc.)   設立  2023年1月26日　   資本金  100百万円（資本準備金を含む）  ※2023年12月末時点  所在地  東京都渋谷区渋谷二丁目24番12号   渋谷スクランブルスクエア   従業員数  72名 ※2023年12月末時点  経営陣  代表取締役　山﨑祐一郎取締役　　　原大輔   取締役　　　青沼克典   社外取締役　大谷仁人   監査役　　　萩野矢宏樹事業内容  クラウドとAIを中心にしたインキュベーション   テクノロジー企業への投資     MISSION テクノロジーでお金と経済のあり方を変える     世界を解き放つ      VISION 会社概要

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

©2024 Metaps Holdings, Inc. ©2024 Metaps Holdings, Inc. 5 インフラ基盤アプリケーションが動いてる環境アプリケーションのエラーをトラッキングするツールオンコール担当 (SRE) に障害をエスカレーションするサービスインフラ基盤の監視エラートラッキングオンコール通知 srestは各種インフラサービスのインテグレーション先となり、各サービスのイベントログを集積‧可視化する基盤にイベントログの集積‧可視化システムメトリクス監視ツール 5 5 無料トライアル実施中＞

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

©2024 Metaps Holdings, Inc. 敷居が⾼そうに⾒えるSRE AWSよりサイト信頼性エンジニアリング（SRE）は、ソフトウェアツールを使用して、システム管理やアプリケーション監視などのITインフラストラクチャタスクを自動化する方法です。組織はSREを使用して、開発チームからの頻繁な更新の中でソフトウェアアプリケーションの信頼性を維持します。ソフトウェアを使用して大規模システムを管理する方が、数百台のマシンを手動で管理するよりも持続可能であるため、SREは特にスケーラブルなソフトウェアシステムの信頼性を向上させます。  https://aws.amazon.com/jp/what-is/sre/  PagerDutyより「SRE（Site Reliability Engineering）」とはシステム運用方法の一つで、日本語では「サイト信頼性エンジニアリング」と言います。Webサイトの安定的な運用を支えるための方法論として、Google社が2004年に提唱しました。SREの大きな特徴として、「信頼性」をシステムの重要な機能の一つとしてとらえている点が挙げられます。システムの信頼性を確保し、より良いサービス提供につなげるためのツールやアプローチ方法を常に模索します。例えば、繰り返しの作業や煩雑な手作業の削減、ソフトウェアを使用したITインフラにおけるシステムの自動化などに注力します。  https://www.pagerduty.co.jp/blog/what-is-sre/ 

Slide 10

Slide 10 text

©2024 Metaps Holdings, Inc. 敷居が⾼そうに⾒えるSRE ● 組織や⽂化の変⾰に⾔及するものも多い ● リーダーシップとか⼈を動かす⼒が必要そう ● たくさんSaaSやOSSを駆使している ● 必要な知識の範囲がとても広い（インフラ、アプリケーション、CI/CD、セキュリティetc.） ● 規模がでかい ● 開発者とともに作るSite Reliability Enginieering ( https://speakerdeck.com/chaspy/sreing-with-developers )  ● エンタープライズ企業でのSRE立ち上げ挑戦の際に意識した事と気付き、現在地とこれから (https://speakerdeck.com/aeonpeople/sre-next-2023-entapuraizuqi-ye-denosreli-tishang-getiao-zhan-noji-niyi-shi-sitashi-toqi-fu-ki-xian-zai-di-tokorekara )  ● SREの組織に適したリーダーシップ理論の模索( https://speakerdeck.com/kenta_hi/srenozu-zhi-lei-xing-niokeruritasituhunokao-cha?slide=12 )  ● アラート駆動でログやメトリックを自動収集する仕組みによる恩恵 (https://speakerdeck.com/mashiike/warningaratowofang-zhi-sinai-aratoqu-dong-deroguyametoritukuwozi-dong-shou-ji-surushi-zu-miniyoruen-hui )  ● 増え続ける公開アプリケーションへの悪意あるアクセス。多層防御を取り入れるSRE活動。 (https://speakerdeck.com/yoshiiryo1/zeng-esok-kerugong-kai-ahurikesiyonhenoe-yi-aruakusesu-duo-ceng-fang-yu-woqu-riru-rerusrehuo-dong )  ● LINEスタンプのSREing事例集: 大きなスパイクアクセスをサバうた目のSREing( https://speakerdeck.com/line_developers/new-year-greeting-preparation-in-line-sticker ) 

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

©2024 Metaps Holdings, Inc. SREはシステム開発‧運⽤業務の業務改善活動 ● Service Level Objectives ○ 投資判断に使うKPI。判断に使えるならなんだっていい。 ● Eliminating Toil、Release Engineering ○ 業務効率化 ● Simplicity ○ いわゆるECRS（Eliminate, Combine, Rearrange, Simplify）

Slide 15

Slide 15 text

Slide 16

Slide 16 text

©2024 Metaps Holdings, Inc. 業務改善活動だと思えば敷居はない ● デプロイ難しすぎてAさんしかできない。Aさん忙しくてデプロイできない ○ デプロイスクリプト書く ● 本番環境で1つリソース作り忘れてコケる（チェックリストはあったんですけどね、、） ○ IaC化して確実に同じもの揃うようにしようか ● 各AWSアカウントにMFA使ってログインし直すのが地味に⾯倒、、 ○ Swich Role？Identity Center？今使ってるIDPからログイン？ ● ⻑⼤なメソッド多くて理解しにくい ○ lintいれてこれ以上は埋め込まないようにしようか ● なんか上⼿く回ってないけど何していいかわかんない！ ○ 勉強会しよう、コンサル⼊れよう

Slide 17

Slide 17 text

Slide 18

Slide 18 text

©2024 Metaps Holdings, Inc. ⼩さな改善と⼤きな改善は分けて考える ● ⼩さな改善 ○ 普段からこれちょっと⾯倒だよね、を意識してみる。改善案は即実⾏。 ○ 改善結果を振り返ってみる（KPT） ● ⼤きな改善 ○ ⾃分だけで抱え込んではいけません！ ○ しっかり課題分析や対策検討を実施した上で意思決定者を巻き込むべき ○ 課題分析の時間もとれないのなら、課題があると折につけ声を上げる ○ こと⼤きな改善については業務改善系のいい書籍がいっぱいある ■ 改善議論には実際に業務をしている⼈を巻き込む ■ 上から改善の意義を ■ 伝え⽅の⼯夫をする（広報や総務(コミュニケーションと環境設定のプロ)を巻き込む） ■ 提案者と実⾏者は分ける ■ ↑「業務改善の問題地図」より

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

©2024 Metaps Holdings, Inc. 余談：ソリューションを使うことが正解ではない ● オブザーバビリティツールで分散トレースしましょう！ ● SLOを作りました！⾒てください！ ● CI/CDはマストです！⼿作業をこちらのパイプラインに乗せてください！ ● 今時Dockerです！コンテナ化しましょう！ ● ECSだ！k8sだ！ ● いまどきPHPはね、、、いけてるRustで作り直しましょう！ ● サーバーの⾃動復旧やオートスケーリングをしないなんて考えられないです。

Slide 24

Slide 24 text

Slide 25

Slide 25 text

©2024 Metaps Holdings, Inc. 余談：ソリューションを使うことが正解ではない ● オブザーバビリティツールで分散トレースしましょう！ ○ ログで⼗分なことも多々あります ● SLOを作りました！⾒てください！ ○ SLOを必要とする課題感を現場や経営層は持ってますか？ ● CI/CDはマストです！⼿作業をこちらのパイプラインに乗せてください！ ○ ⼿作業にどれだけかかっていますか？ミスはどれだけありますか？ ● 今時Dockerです！コンテナ化しましょう！ ● ECSだ！k8sだ！ ○ コンテナに載せ替える労⼒に⾜るメリットはありますか？ ● いまどきPHPはね、、、いけてるRustで作り直しましょう！ ○ 作り直してどれだけなんの改善が⾒込めますか？ ● サーバーの⾃動復旧やオートスケーリングをしないなんて考えられないです。 ○ ホットスタンバイ1台起動しておくだけで可⽤性⼗分じゃないですか？

Slide 26

Slide 26 text

Slide 27

Slide 27 text

©2024 Metaps Holdings, Inc. SREエンジニアは、業務改善活動のプロジェクトメンバー ● 業務改善活動はチームで実施することが多い。そのチームメンバー。 ● 専任の場合もあれば兼務の場合もあるので、基本インフラエンジニアなんですが、、、という場合でもSREエンジニアでいいと思う ● フロントエンドしかしりません！だったとしても改善チームにいるのであればSREエンジニア ○ フロントエンドの詳細や利⽤ユーザー⽬線での発⾔なんてフロントエンドやカスタマーサクセス系の⼈に勝るものはいない ○ もちろん本気で取り組むなら他の分野のことも知った⽅がいいけど ● もちろんそれを本業としたりコンサルティングをする⼈だったりもする