Tech-on MeetUp#07「OpsとDevの蜜月な関係」参加レポート

TECH PLAY渋谷で開催された Tech-on MeetUp#07「OpsとDevの蜜月な関係」 というイベントに参加してきました。

Tech-on MeetUpとは

imaga

https://techplay.jp/event/734673?utm_medium=email

『技術者同士を、人と人とのネットワーキングで繋ぐ』

技術のトレンドは非常に早い流れで移り変わるのがいまのIT業界の理です。 
ナレッジをきれいなドキュメントに起したり、
それを閉じた組織のなかで共有しているだけでは この早い流れについていくことは絶対にできません。

「Tech-on」では、「ホンモノのナレッジは人と人の緩い繋がりの中にこそある」を信条に 
同じテーマに興味をもつ技術者同士を繋げ、
自らが持っているナレッジを自分の組織の外に 出し合うことで、
お互いがこれまで発見できなかった新しい知的創造を生み出せる 「場」を提供していきます。

今回は7回目ということで「DevOps」がテーマでした。

セッション紹介

Ops meets NoOps ~そのとき何が起こったか~」

  • NoOpsとは「システム運用の嬉しくないことをなくす」を目指すこと
  • コンセプトに共感して何かを始めた人は多いが、導入が進まない企業がほとんど。
  • 「試行錯誤しにくい体制」「いいだしっぺが全部やって」「「SRE」とか「なんちゃらワーキンググループ」とか旗だけ先に立っちゃう」などの環境が原因
  • 今やってること続けながら新しいことは出来ない
  • 積極的にやめて時間を作ろう
    • やめる判断はえらい人の大事な仕事
  • いきなりドリームチームは作れない
    • 持続的な変化は能力より、意欲より意欲が大事
  • どこから始めるのが良いのか
    • Cloud Native Trail Map
    • ただし、実績が出るまで時間がかかるので、おすすめはObserbavilityから
  • なぜObservabilityから始めるのか
    • プロビジョニング/構成自動化より効果が出しやすい、効果も出やすい
    • 監視が不要な組織はない
    • エンドユーザーへの影響が少ない
    • Opsが道場になる
      • 監視システムをNoOpsコンセプトで作ってしまおう
      • そこから知見を展開していけばいいのではないか
  • SREはほとんどが「Avalability」の文脈で語られる
  • 共通指標(SLI/SLO)を定義することでビジネス/Dev/Opsのチームワークが生まれる
    • ビジネスオーナーにSREの重要性が理解されなかったらMicrosoft Leanを見せるのをおすすめする
  • そしてそれらを把握する仕組み(Observability)を作ろう
  • なくしてもなくしても、Opsの仕事はきっとある
    • なくせるOpsの需要が高まっていく

「チーム開発におけるDevとOpsのプラクティス」

  • 開発(スクラム)と運用(複数件運用)でゴールが違う
    • 実際に運用するメンバを開発チームに入れ、非機能要件をバックログに入れt
    • 運用も開発のチームの一員となり、ゴールを統一した
  • 現代のシステムは分散化されて複雑
  • 新規サービスのリリース前に重厚な障害テストを行っている
  • Chaos Engineeringをstg環境でやっている
    • 運用と開発合同で実施
    • いつ、なんの障害を発生させるかは言わない
    • 実際に障害が発生したとして障害対応する
  • gremlinを使っている
    • リソース、ネットワーク、ステート障害などを起こすことが出来る
    • GUIから操作可能
    • 複数障害パターンの保存、自動化が可能
  • 障害訓練の効果
    • コンポーネント障害のユーザー影響がわかる
    • 障害手順書の不備がわかる
    • 実際の障害状況に違い環境で訓練出来る
    • システムを改善する機会が得られる

LT会

SRE はじめの一歩

Slackによるインシデント対応

MLOps

Microservice x ScrumなBtoB_Webアプリケーション開発現場のOps

ZOZOTOWNを支えるチーム運用について

感想

Tech-on MeetUpというイベントは今回初めて知ったのですが、 過去のテーマを見るとその時の技術トレンドにフォーカスしたものを毎回テーマを変えて行っており、 また時間の都合がつけば参加してみたいなと思いました!