【レポート】NoOps Meetup Tokyo #6

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

Observabilityを支えるStackdriver

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

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

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

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

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


サイボウズクラウドのインフラはオンプレ
手作業、トイルが多い
手順書作る、レビュー、リハーサル、本番環境で手動適用

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

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

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

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

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

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

業務分類

  • OKR work
  • 目標達成タスク

  • project work
  • プロジェクトのタスク

  • toil
  • 繰り返される運用

  • overhead
  • 採用や会議、調整業務

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

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

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

コメントを残す