NoOps Meetup Tokyo #6に行ってきました。レポートというかメモ書きですがシェアしたいと思います。
Observabilityを支えるStackdriver
SREとはdevopsの実践方法で意思決定にデータを用いる SREを実行するためのデータは ・SLI、SLO、SLA ・エラーバジェット ・ユーザーの幸福に繋がる指標 がある。
SLOはシステムの提供できる価値と許容できる値 SLIとなるメトリクスの取得と収集が必要 SLO違反に対応するための体制が必要
クラウド化によって従来のOSやハードウェアの監視の負担は軽減されてきているので、アプリケーションとして価値が提供できているかが重要になってきている。
Stackdriver製品を使っている。 GCPとAWSに対応 複数のサービスにまたがったトレースもできる 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でジョブキューの可視化、新着バグを通知