#6 #ssmjp 2017.12 ブログ枠の完走の感想

  #ssmjp  [Public]
icon Kei was written at Dec 14, 2017 12:29 PM
  Edit(Sign in)
  Stock
  Answer survey

  TOC

#ssmjp 2017.12 ブログ枠です

また途中からだぜ…19時定時はきついぜ…
2017年12月の#ssmjpに参加した完走の完走です


SRE本の歩き方(tcshさん)

  • 自動化は万能薬ではなく、考えなしに自動化をすれば、解決した問題と同じだけの問題を作り出す
  • 壊れたものを治そうとしたけど開発者たちは見つかりません。臨機応変に対応しましょう!

Q&A

  • 最後の臨機応変は、運用でカバーと何が違うの?
    • ちゃんと報酬をもらえるんじゃないだろうか? 繰り返すような運用でカバーでなく、少なくとも解決をしていってるのではないか。

感想

  • 開発した人居ないあるあるはやはり地獄感があり、かなり頷ける内容でした。


もしそこらへんの運用担当者が波田野 裕一の『「運用改善」を考える 〜「自動化」を考える前に』を読んだら(もしハタ)(typhon666_deathさん)

  • イベントコンパニオンの歩き方を100回目で話しました
  • 某セキュリティ会社で色々やってます。OWASP / AIsecJP / WBAI / Sec-JAWS / Fin-JAWS / X-techJAWS
  • デートアプリも喋りました

  • はたのさんを1台購入発言

    • 予算取りがだいじ
    • 言ってたら登壇することになった
  • この夏、インターン生が来た

    • 運用改善、製品検証をしようとしてた
      -「 運用設計には痛みの経験が必要なので、ちゃんとした運用改善ができるインターン生は全力青田買い」(はたのさん)
    • はたのさんの資料を読んでもらってからインターンしてもらった
    • ラックの竹田さんの資料も
  • ツイート禁止のところもあるよ!

  • 異動してからの衝撃

    • 運用の部署なのになんでこれないの?みたいなことばかりだった
    • 二年経ったけど引き継ぎされてない気がする
    • しばらくチームメンバを監察(原文ママ)し続けて二週間
  • ×運用でカバー ○残業でカバー

  • (うちの会社の人いますか?に対して会場から手を挙げながら「はい!いいよ気にしなくて!」という声が飛ぶ)
  • 問題と思ったこと
    • 顧客情報がメーラと営業の頭の中にしかない
    • チケットもアレ、催促も1ヶ月前のやつに返答できてない
    • アウトソースしようにもドキュメントがない
  • 運用としてやるべきことは何か?
    • 自動化?そうじゃない
    • 対策方針通りにやったら、アウトソース→巻取り→アウトソースになりそうだった
  • 現状把握が第一優先
    • ばななフレンズ量産計画の阻止(あたまがわるいひと)
  • PDCA回してられない、See/Plan/Do でないとだめ、現状把握第一
    • Pの過程で運用設計を想定する
    • とりあえず考えて実行、繰り返し
  • やったことは他部署に共有
    • グループ会社も巻き込んで共有できることは共有
  • やったことは色々ツールつかったよ(禁則事項です)
  • インターン生に与えていた宿題ははたのさんのスライドだけ
    • 非常にいい形でアウトプットしてくれた
    • 初めから運用部門と開発部門が手を取り合ってたら少しは幸せなのかもね…
  • まとめ
    • S->P->D

Q&A

時間がないので省略

感想

かなりの言いっぷりだったので、微妙に全部ここに書くのはやめています。
やはりみんなそうなんだなあ、という印象でした。



「手順書の話」(とがくしさん)

  • 大阪から来て喋ってまた帰ります
  • 手順書の話は3回目です
  • Sierの中で働く人の話です
    • ほとんどオンプレ
    • 強制エクセル方眼紙
    • 人材もピンきり
  • 個人の見解です
  • えらいひとには承認してもらおう
  • ゴールはなに?
    • やりたいことが達成できる?
    • 誰でもできる?
    • イマイチ
  • 仕事の捉え方
    • INPUT -> PROCESS -> OUTPUT
    • 仕事は必ずこれに分解できると思ってる
  • 手順書も分解
  • (例)サーバを再起動する
    • INPUT(目的)
      • 再起動したい
    • OUTPUT(結果)
      • 再起動した
    • PROCESS(手段)
      • 順番が入れ替わるのもありえる
  • 手順書とは
    • PROCESSの部分を並べたもの
  • PROCESSの練り込み
    • プログラムに似ている
      • 人を処理する
      • エラーが起きたら止まればいい
  • PROCESSの粒度
  • 5W1H
    • チェック項目として利用、すべて明確であるかどうか
    • モノ(サーバ)目線
    • ヒト目線
  • 確認
    • INPUTとOUTPUTがはっきりしてるのでテストもかけるんじゃないか
  • いい手順書
    • 明確、エラーで止まればいい
  • 悪い手順書
    • 不明確、考えることが多い、準備不足
  • 【性能測定】時間の見積もり
    • 熱湯3分
      • カップラーメンが出来上がるまでの時間じゃない
        • カップラーメン買ってくるとかそこら辺が省かれてる
    • PROCESSの実行時間だけを見積もってたら足りなくなる、意外に準備に時間を取られる
  • 手順書の最適化
    • 共通部分は共通化
    • やりすぎるとわかりにくくなる
  • 【デバッグ】トラブル
    • じこはおこるさ(トーマスの挿入歌)
      • イライラすると事故が起きる
      • ちょうしのってやってるとバチが当たる
      • 歌詞を読んで!ようつべをみて!いいこと言ってる!
  • まとめ
    • 異常発生時は止まれるように
    • 作り込みすぎないように

Q&A

  • gdgdになりそうなときはどうする?
    • 結局上から言うしかない
    • レビューするしかない、3回はやってる

感想

大阪出張だったとがくしさん、大阪から来て話して大阪に戻っていかれました。すごい。
9月の内容のアップデートだったんですが、トーマスの歌詞かなりすごい。
物理インフラの手順書を参考にするのはとてもいいかもしれないですね。



運用自動化、不都合な真実(tcshさん)

  • とがくしさんの職場は8年住んでた場所の跡地
  • tcshさんの博論は手順書を作るための手順書みたいな感じになってる
  • JAWS-UG 手順書支部がある。転職支部みたいになってる。

  • 「運用自動化」ひどい目にあったことはありませんか?

    • みんな手が挙がる
  • 運用自動化がなぜ大好きなのか
    • 実装者は楽しいし褒められるしノリノリ
    • 管理者はみるみる改善するようにみえるからノリノリ
    • メンバーは(XXができるなら)OK
    • これは人類の夢だからだ!
  • 経験値が高いメンバーほど懐疑的
    • 運用でカバーが若干残る、隠れ運用でカバーが永続カード発動!
  • 破綻顕在期
    1. 諸々のEOL
    2. 業務仕様や業務フローの変更
    3. バグの顕在化
      • 仕様バグ、やっつけ実装、環境変化による挙動不審
      • 結局メンバーが頑張って修正
  • 破綻炸裂期
    1. 業務遅延発生
    2. 信頼性低下、遅延発生
    3. 業務停止
  • 運用自動化 負のループ
    1. 導入期
    2. 破綻潜伏期
    3. 破綻顕在期
    4. 破綻炸裂期
    5. 忘却期(3〜4年)
    6. 手が上がりまくる会場
  • 運用自動化は運用標準化の一つ
    • すべて実装まで行う必要はない。実装するところで工数の谷がある
    • 自動化すれば定型化される わけではない
  • 標準化・自動化は目的になりやすい
    • 見える成果につながりやすい
    • 本気で改善したい人がいる一方で、成果だけ出したい人にお手軽なため、焼畑的なことをしがち
  • 焼畑農業的な標準化・自動化をする人に注意
    • レイヤの高いところをやるとあとで面倒になる
  • 不都合な真実1
    • 標準化・自動化は、業務を硬直化させる
    • その業務についてそれしかできない人を生む、お役所仕事しかできない現場に
  • 不都合な真実2
    • やれるところから自動化 は弊害を生む
    • 保守も変更もできないモノリシックな自動化群の誕生
      • なんだろう、フロントエンドのビルドツールの話でも聞いているかのようだ
  • 不都合な真実3
    • 自動化の寿命は、期待したよりもずっと短い
    • 資産と思って頑張った自動化が、あっというまに負債化
      • Chef…アッアッ…今はAnsible…アッアッアッ
  • 対応1
    • 自動化の寿命は短い→自動化は使い捨て
      • 拡張性や汎用性はある程度でよい、陳腐化したらバッサリ捨てて
      • クラウドで使い捨てなのになんでコードや実装が使い捨てにならんのだ
      • でも設計と経緯は残そう、それがノウハウ
  • 対応2
    • 自動化は外部との接点から実施する
      • 仕様変更に外部との調整が必要なところから手をつける
      • 外部に影響しなければ、自在に変更・改善することができるようになる
      • 人と一緒に仕事してるからそこからやんないと
  • 対応3
    • 小さく自動化
      • 疎結合・分散型の小さなツールを作る
      • UNIXという考え方 を読んでからSRE本を読もう
  • 重要:運用自動化をしっかり実現するには
    • 使う人が自分で作るしかない、内製しよう
  • Whyのわからないツールは改修できない
  • ドキュメントは資産、ツールは揮発物
  • 工程を意識する
    • 手順書の話と一緒
  • 場所が複数になる場合は分割する
  • 作業手順の主目的で4つに分類する CRUD、RESTの考え方と一緒
  • 自動化の経験則
    • 成功
      • 明確な効果のもの、疎結合なもの、目的を明確にし、トップダウンで作成したもの、手順書に沿って作成したもの
    • 失敗
      • 手近なところからボトムアップ、自動化を目的にしたもの、夢のツールを目指したもの
  • 運用自動化よりも運用構造化をまず目指す
  • サービス価値の上がらない自動化はビジネス的に無価値
    • 工数使い込むのダメ絶対
  • 技術的に正しい話と、ビジネス的に正しい話は別
  • 工数削減いうな
    • 工数が増えても提供価値がそれ以上に増えればいい
    • 運用価値の削減を目指すとゼロになるまで止まらない、これ部署ごとなくなる
    • なすべきは効率化、アウトプットの増大が目的
  • 手動に戻せない自動化は素人仕事
    • 手動対応まで想定するのがプロ

Q&A

時間なくなったのでまた懇親会で

感想

Chefwwwホントすみませんでした前職の方…
もうね、こんなん作っては捨てするしかないですわ。


全体の感想

はたのさん祭りということで、運用の勉強会らしい内容となりました。
会場からは拍手や頷きが多々見られ、さすがにみなさん辛い経験をされているなあと。
Whyと、そこにいたる経緯、それだけは必ず後に残さないといけないですね。
ツールは揮発性とはいえ、業務がツールに従える状態を整え続けていられるなら、
それはそれである意味幸せなのやもしれません。

 Attach Files     - [0]


 Add Comment