nykergoto’s blog

機械学習とpythonをメインに

トップ > めも > システム運用アンチパターン・本読み section2&3

システム運用アンチパターン・本読み section2&3

めも

社内本読みの記録です。GOTO・MEMOが僕のメモ/Discussionがその内容を社内で議論したときの記録になります。

§2: パターナリスト症候群

GOTO・MEMO

キーワード: ゲートキーパー

  • 承認における「決定権を持つ人」の比喩
  • ゲートキーパーはなにかイベントがあって発生するがあってもプロダクトのクオリティ向上には繋がっていない
    • 歴が長いグループだとゲートキーパーたくさん居るイメージ。
    • クオリティのうちのリスクの重み付けがとても大きい会社だとゲートキーパーは必須になってしまうのではないか? この作者の重み条件では最適化するとゲートキーパーは要らない、と言っているに過ぎないような (例えば医療系などミスったら大変なものはゲートキーパー必要と思う)
  • この作者が大事にしているところ
    • 人間のコスト / 煩雑さによる生産性低下
    • 人間のリスク / 「ルールを守らなかっただけでしょ!」とはいえ誰でもまちがえるくない?

自動化の方法

  • p:20 どうやってやるかの最初のステップは「みんなでメリットを共有すること」。
    • 気持ちの統一が大事。
    • 解決の方法には注目しない。
    • [atma的には] お客さんに提案するときもなにやるか先行じゃなくて先に問題を認識してもらうフェーズ入れたりしたほうが話早いかも。
  • エラー処理はこらず、全情報を出すことに集中する
    • [atma的には] フロントエンド実装とかにも言えるかも?

Discussion

ソフトウェア会社に対しての調査

  • 開発外の人が品質保証で入っても品質が上がらない
  • ウォータフォールでもアジャイルでも変わらない
  • 車の開発：外部に不必要・内部に必要なのでは? 現場の人が最終の品質担保に関わるのが良いのでは?

具体例: 開発におけるレビューというフェーズ

  • レビューはもっとも近いゲートキーパーなのではないか。
  • となると、本論通りゲートキーパーが不要なのならば、レビューも究極の形では自動のほうが良い?と言えてしまう
  • ただしレビューはゲートキーパー以外の役割(例えばコミュニケーションや指導など)もあり、正の外部性があるため採用されていると考えるのが良い。
  • レビュー基準として「レビューは早くやる」とよく言われる。これはゲートキーパー的な機能を減らすためともいいかえることができる。
  • 結論レビューに置いても、ゲートキーピング的な役割は少ないほうが良い。できる限り人のタスクを止めないように確認作業をしてマイナスの効果を少なくし、正の効果を受け取れるよう運用するべき。
  • だめな例: 他のPJからきたあまりContextがわかっていない人のレビュー
    • 単なるゲートキーピング化しており正の外部性が小さい

§3: 盲目状態での運用

GOTO・MEMO

  • アプリが何しているかを確認して共有しろ。意外と知らないよ。
    • 難しいドメインのものもそうだし、かんたんでもフローを完全に理解していないとメンタルモデルが間違っていることがあるので、注意しないといけないと思った。
  • 見るものを見ろ。取れてるものを見るな。
    • はい。
    • [atma的には] とくにぐるぐるではアプリが動いていることと問題ないことに差があるので、メトリクス定義して見るようにしたほうが良いかも。たとえば…
      • 1時間あたりの submission の増加数 (submissionが急に無くなったりするともしかすると submission POST のエンドポイントが止まっているかもしれない。)
      • あるいは、1時間あたりの submission エラーの増加数 (もしかしたらスコア計算のコードはおかしくないが、答えのデータなどの設定側がおかしくってエラーが増えているかもしれない)
  • とりあえず取れるログはいっぱい取れ。何かあったらすぐその良さに気づく。
    • 著者、なんかあったんかな…
    • [atma的には] そもそも取ってないやつが多い (cloudwatchには吐き出している?) 500エラーに対してのログなどを定期的に見る癖をつける必要があるかも。
  • logを取る系のサービスは使え。メンテコスト払えるのか?
    • 確かに。作らないのが一番バグらないと通じるところがある。
    • 自分の作業単価を考えてどの作業をするかを考える。

ref:

Discussion

よく使っているログツールのこと

  • cloudwatchlogs単体だとドメインの情報が全く乗っていない
  • アプリのコア部分・ステータスの状態遷移が多いものは何処で何が起こるかわからなくなる
  • 状態変更時にログを吐くような設計のほうが、あとあとで何が問題だったか追いやすい (ex: 対象のオブジェクトが時系列で更新される場合、ログがないとエラー時の状態を復元できない)

ref: ログをかんたんに取るツール

  • cloudwatch / amplify
  • sentry

ログを取る基準って何?

  • 複雑度が高い難しめのところ
  • 状態がころころと変わるもの (mutableに変更される object)
    • [ｷｹﾝ] status column を持つ
  • バッチ処理 (multi-tenant)
    • いろんなテナントまたいで処理するため何処でエラーになっているかわかるようにする
    • テナントごとにちゃんとできた・できなかったがわかるようにログを取る必要がある

どこからログを取る?

  • 全部でなくて大事なところからはじめていく
  • ビジネス的に大事なところ

ちょっと抽象的なのでルールを作りたいかも…

  • 案1: 更新系・登録系は全部対象とする
    • request / response
    • nginx / uwsgi のログに仕込む
    • AWSの ALB (ただし body は見れない)
  • ただしログイン系はマズイので除外する必要がある
  • 「全部でなくて大事なところからはじめていく」の原則に乗っ取ると、全部を一気にする〜というのはヨクナイのかも。ビジネスの重みを考えて、徐々にはじめていく。「みんなでメリットを共有すること」大事。
  • なんか結局著者が言っているところに落ち着く…この著者、天才なのでは…?!