tsalakh ain sus noam Huyah ol guf

勉強会のメモ。その他備忘録。参考にさせて頂いたサイトや資料はリンクさせて頂いていますが不都合があればご連絡ください。

【勉強会】NoOps Meetup Tokyo #6

2019-06-04_NoOpsMeetupTokyo#6

noops.connpass.com

GCPのObservebility - Stackdriverの紹介

Observabilityを支えるStackdriver(Google 山口さん)

docs.google.com

SREとは

システム信頼性のために方針を持ってDevOpsを実践すること

信頼向上のためには、

  • 意思決定は主観でなく、データに基づく
  • 運用の課題をソフトウェアエンジニアリングで解決する

SLI/SLO/SLA

  • Indicatorは単なる指標、Objectiveが許容できる限界値、Agreementは規約
  • SLOを100%にするのは意味がない
  • システムの入れ替えが不安定なことは回避できない
  • 不安定をどの程度許容できるかを定義するべき

エラーバジェット

  • 許容可能なエラー率

オブザーバビリティ(可観測性)

  • システムを運用する上に置いて、判断に必要な情報が取得できる状態であること
  • 従来のモニタリングでは、ハード・OSを見ていた、クラウド化で軽減された、そこでAPMが重要になってきた

GCP向けのオブザーバビリティソリューション=Stackdriver

通常運用時の取得情報

  • メトリクス
    • 「統計的に」全体が問題なく動いているか、外形監視など
  • アラート
    • SLO違反が発生した場合の見地
  • カスタムメトリクス
    • アプリケーション固有で取得したい指標、ある処理の処理時間やファイルサイズなど、ユーザビリティに繋がりそうな指標

高負荷・調査のための情報

  • プロファイラ、
  • 分散トレース、MicroServiceで複数サービスをまたがったトレース

障害調査のための情報

  • エラーレポート
  • IRM:Incident Response and Management:インシデント管理

2000台オンプレのコンテナ化 - Necoプロジェクト

物理データセンターでも NoOps(サイボウズ 山本さん)

speakerdeck.com

Necoプロジェクト

  • 国内数カ所のDC、サーバ数十台のアーキのまま現在の数千台へ
  • Kuberantesを採用
    • 物理サーバに依存させない
    • 自作からの脱却
    • 拡張性に優れた設計になっている

典型的なToil - プログラムの更新作業

  • 手順書を書き起こす
  • 手順書をレビューする
  • アドホックに自動化
  • 開発環境でリハーサル
  • 本番環境で、ペアで手動適用

こうありたい

  • 撃ちっぱなし可能な宣言的オペレーション
  • 継続的デリバリー

Necoの設計原則

  • Be Declarative
    • Kubernetes以外もすべて宣言的に操作可能にする
  • Define by Software
    • サーバ・NWは目的に依存しない、ソフトウェアで制御する
  • Test Everything
    • DCで動作するすべての機能を自動試験する

SREの実践例とプラクティス

NoOpsを実現するSREの存在意義と役割(Studist かつひささん)

speakerdeck.com

NoOpsとは

DevOps focus Collaboration, NoOps focus Automation

  • Opsを職種や役割と捉えると議論がちゃんとできない
  • Opsを業務軍と捉えると、その一部を自動化することはごく自然なこと

SREとNoOpsの関係

"No Comfortable Ops"の思想は、SRE本でいう"Eliminating Toil"と似ている

Toilとは、何回やってもサービス成長に寄与しない繰り返し作業

Toilの撲滅の実践例

撲滅するためには、まず対象を計測する必要がある

Toilの計測

業務を分類した

  • Software engineering/設計・製造 =OKR達成に関連するタスク(と定義)
  • Systems engineering/システム構成変更 =Issueベースで取り組むタスク(と定義)
  • Toil/反復的な手動作業
  • Overhead/チームや組織のMTG

週単位で集計

  • カンバンのレーンを分けてタスク管理
  • 作業にはすべてポイント付与
  • ToilとOverheadはバックログにはなく、発生都度ポイント付与しカンバンに追加
  • ベロシティよりも作業時間割合の計測をより重視、チームの時間の使い方を重視する

計測ができれば、目標値が設定できる →今年は5〜10%が目標

どうやってToilをここまで減らしたのか

Toil Management Strategies(SRE WorkBook)を参考にする

SRE wookbookから3つ抜粋

Engineer Toil Out of the System

Toilを減らす前にシステムを変えられないか、Toilを増やさないことを考える

  • Toilを増やさないために、Design Documentを書く
    • 初めの設計の段階で、(ゼロにはできないが)できるだけ減らす
    • 不可逆性の高い部分
    • 性能面で詰まる可能性の高い部分
    • なぜその設計だとダメなのか
      • DesignDocumentは必ず書く、障害を収束させた人より障害を産まなかった人を評価

Use SLOs to Reduce Toil

SLAは規約だが、)SLOではダウンタイムを許容する

  • 許容できない、ではなく、許容できるとしたらどれくらいかを真剣に考える
  • 必要以上に性能目標を高くしすぎないことで、Toilの膨張を防ぐ

Provide Self-Service Methods

開発者から依頼を受けて仕事をするのではなく、開発者自身がやってくれるようにする

  • チケット駆動の依頼方式は、組織の経済的な無駄を生む
    • 依頼仕事は減らして、セルフサービスにしよう
  • 開発者がOpsを実行できるように、適切な権限を与える
    • Define/Execute/Govern(定義/実行/ガバナンス)
    • AWS Organizationを活用して、権限制御することでガバナンスを聞かせる
  • デプロイの責務を開発者に移管する
    • GitHubへのPullからリハ環境(PRD同等環境)までは自動でデプロイ実行
    • 承認ボタン押下でPRD環境へデプロイ実行
  • 開発者の改善を促進するための情報を可視化する
    • レイテンシの計測
    • 非同期処理のジョブキューの滞留状況を計測
    • NewRelicのApdex(ユーザの使用性の満足度的な)
    • エラーレート
    • ログの分析はElasticsearch/kibana

Recap

  • NoOpsの実践に、SRE本は最高の教材
  • DevOps 3つの道に忠実に
    • フロー改善、フィードバック、継続的な学習と経験