【レポート】NoOps Meetup Tokyo #6

NoOps Meetup Tokyo #6に行ってきました。レポートというかメモ書きですがシェアしたいと思います。

Observabilityを支えるStackdriver

SREとはdevopsの実践方法で意思決定にデータを用いる SREを実行するためのデータは  ・SLI、SLO、SLA  ・エラーバジェット  ・ユーザーの幸福に繋がる指標 がある。

SLOはシステムの提供できる価値と許容できる値 SLIとなるメトリクスの取得と収集が必要 SLO違反に対応するための体制が必要

クラウド化によって従来のOSやハードウェアの監視の負担は軽減されてきているので、アプリケーションとして価値が提供できているかが重要になってきている。

Stackdriver製品を使っている。 GCPAWSに対応 複数のサービスにまたがったトレースもできる sentry的なアプリケーションログのレポートもまとめてくれる

物理データセンターでも NoOps

https://speakerdeck.com/ymmt2005/wu-li-detasentademo-noops サイボウズクラウドのインフラはオンプレ 手作業、トイルが多い 手順書作る、レビュー、リハーサル、本番環境で手動適用

2018年からリプレイス計画始動 kubernetes中心 物理サーバに直接依存させたくない コンテナ・マイクロサービス時代の勝ち馬 拡張性が高く設計が優れている

kubernetes以外も全て宣言的オペレーションにする 特定の目的に縛られたサーバ・ネットワークを作らない データセンターで動作するすべてを自動テストする →ぶっつけ本番をしたくない

kubernetes管理ツールCKE  ・kubernetesクラスタの運用を自動化  ・望みのクラスタ構成を宣言するだけ

仮想データセンターを活用したCI/CD  ・開発者用のデータセンターがほしい  ・pladematというツール   ネットワーク(スイッチ)、ルータ、サーバをYAMLで管理 電源停止後の動作確認もできる

NoOpsを実現するSREの存在意義と役割

https://speakerdeck.com/katsuhisa91/class-sre-implements-noops

トイルをどうやって計測するか SREはトイルを50%以下にしないといけない

業務分類

  • OKR work
  • 目標達成タスク
  • project work
  • プロジェクトのタスク
  • toil
  • 繰り返される運用
  • overhead
  • 採用や会議、調整業務

カンバンで分類ごとにレーンを作る すべての業務にポイントを付与 作業時間割合を計測

そもそもトイルが生まれないようなシステム開発が必要 障害が生まれにくいような設計 より信頼性の高いコンポーネントに置き換える(AWSのマネージド使うとか)

デプロイの責務を開発者に移管 開発者がデプロイボタン押したらデプロイ 開発者による問題検知ができるようモニタリングする stacdrierでジョブキューの可視化、新着バグを通知