はてなの金次郎

とあるエンジニアの技術系ブログ

SRE がよく利用するソフトウェアの理解と分類講座に参加しました

SRE 勉強会

感想

supporterzcolab.com

サポータズCoLabの「SRE がよく利用するソフトウェアの理解と分類講座」に参加しました。

SREエンジニアとして働くためには並大抵ならぬ努力がいることを感じざるを得ませんでした。

一方で、SREエンジニアとしての働き方にかなり興味を持ったのも確かです。

「自動化」 ・「制御してやったという達成感」

SREエンジニアとしてのモチベーションを尋ねたときの回答です。

それを聞いたとき、はじめて自分が書いたCIのymlが期待通りの挙動をしてくれたときに幸福感を感じたことを思い出しました。

コードをゴリゴリ書くことが1番の楽しみでしたが、なるほどそういう働き方もあるなという気づきをいただきました。

「一番困っていることから手をつけるのが良い」

オススメの勉強方法です。まずは課題を見つけるところから少しずついらいろな技術に精通していけたらと思います。

裏の勉強会がかなり盛り上がっていたようですがこちらの勉強会に参加してよかったです。

帰宅後、それぞれのサービスをググって概要だけでも眺めてみましたがかなり全体像がつかめた気がします。

今回紹介していただいたサービスだけでも

な、なな、なんと

43個

ありました。（驚）

全てに精通する必要はないですが、どういったツールなのか、どういう違いがあるのかくらいは理解しておきたいですね。

speakerdeck.com

以下、メモ書きです。

メモ書き

自己紹介

  • 北野勝久さん
  • スタディストSREチームリーダー

困っていたこと

  • コード管理されておらずブラックボックス化したインフラ
  • 障害が発生してもモニタリング・管理が貧弱で状況がすぐに掴めない
  • 何からやったらいいかわからないし周辺技術もたくさんある

ひらすら勉強

  • 効率最悪
  • 時間の無駄

これを知ってれば

  • SREの全体像をみれていれば...
  • 闇雲に走る必要はなかった

SRE?

  • Google発
  • システム管理者, DevOpsとは何が違うのか
  • ソフトウェアエンジニアが、システム運用をしたらどうなるか？という観点で再定義されたシステム管理者の役割
  • class SRE inplements DevOps
    • それ以外の役割も担う
    • それ以外の役割は各社で異なり厳密な定義はない

youtu.be

話す範囲

  • 話さないこと
    • ベーススキルセット
  • 話すこと
    • SREの責務範囲の枠組み
    • ツール（AWSメイン）

Infrastructure as Code

Monitoring

Log

  • ログの転送ツール（フィルタリングや加工も可能）

ChatOps

  • Slackなどのチャットツールからコマンドなどを入力することで何かしらの作業を行う

CI/CD

Development Environment

Infrastructure Automation

  • イベント駆動アーキテクチャでインフラ操作自動化することを意図して記載
  • 「○○が起きたら、XXXが起動し、△△する」というXXXの部分

Security

Data

Incident Management

まとめ

  • 全体像を把握し、それぞれのツールの役割を理解するのが良い

QA

  • オススメの勉強方法や書籍
    • SRE book for FREE in English
      • Googleと自分たちの違いを理解する
      • 分散処理が世界で最も強い会社
      • 自分の会社とGoogleとの差分だけ認識して学習する
      • 書いてあることを全て実現するのは無理だし意味がない

www.publickey1.jp