#ssmjp 2019/11 参加レポート
みなさまご無沙汰です。 #ssmjp 2019/11 参加レポート でございます。
今回は感想などをアウトプットします枠ということで最前列に陣取りました。
今日は運用ガチ回ということで、運用ちゃんにも来ていただきました。というわけで早速ツーショットです。
今回のいきさつは波田野さんと沢渡さんのバトルが見たいということで始まったらしい。
ちゃんほさん 「クラウド時代の運用設計」
- menti.com でアンケート取りながら。インタラクティブだ。
- みんな運用担当っぽい
みんな運用に悩んでいるらしい。
- そもそも運用って何？
- システムサービスの本来あるべき姿を提供し続けることを維持すること
- 運用
- 保守
- 開発 (エンハンス)
- エンハンス後はあるべき機能が変わる
- 本来あるべき機能
- システムサービス
- 機能要件
- 非機能要件
- 維持する活動
- あるべき機能にあるか監視する (モニタリング)
- 劣化していれば復旧する (オペレーション)
- 劣化の原因になったものを修正する (リアクティブ 保守)
- 劣化しないか事前に保守シュル (プロアクティブ)
- 運用設計とは
- 維持する活動を実施するためのツールや手順 (方式設計)
- 維持する活動を実施するための業務内容 (業務設計)
- 運用方式設計の話
- 運用に必要なツールやそのオペレーション設計をすること
- ツールの設計
- 監視、ジョブ、バックアップなど
- ツールの詳細設計
- 監視定義 ジョブの内容 バックアップジョブなど
- それらのオペレーション設計
- 操作手順書など
- 可制御性と可観測性
- 運用設計でもこれらが大事
- 状態とサーボスの関係性を正しく把握する 可観測性
- どうやったら正しくコントロールできるか 可制御性
- ツールの設計
- 運用業務設計とは
- 運用を遂行するために必要な業務の定義
- 運用業務設計をしないと
- 目的が何なのかがわからなくなる
- 何を確認するのかがわからなくなる
- 運用者は何をするのかがわからなくなる
- ツールは何のためにどう使うのかがわからなくなる
- 結果として仕組みが有効に働かない
- 方式設計だけ実施して後付で業務を考えると
- 何も設計なしでサーバを設置しちゃったらこうなった (店舗に設置したサーバの例)
- テープ交換忘れ
- テープが見つからない
- テープドライブ故障多発
- 現地にいかないとリストアできない
- ツールからちゃんと戻らない
- EOSをきっかけに方式設計をきちんと
- リストアがまともにできるように
- D2Dにした
- リモートでリストアできるように
- 出張しなくてよくなったかわりに東京で大変な思いをするように
- 出張すると電車や飛行機で強制リフレッシュの時間があった
- リストアがまともにできるように
- 具体的な運用業務設計
- 業務一覧
- フロー
- アクション
- 業務一覧の網羅性 あまねさんの本 システム運用の基本
- 近藤さんの本 運用設計の教科書
- 何も設計なしでサーバを設置しちゃったらこうなった (店舗に設置したサーバの例)
- 運用に必要なツールやそのオペレーション設計をすること
- システムサービスの本来あるべき姿を提供し続けることを維持すること
- クラウド時代の運用設計
- IaaSだとそんなにかわらない
- どっちかってーと業務設計よりになる
- どう作るかよりもどう使っていくかという考えにシフト
- クラウド利用で特に必要になるもの
- クラウドサービス側との連絡ルート
- サービスレベルの管理
- 利用状況の管理と課金管理
- 無駄に使われていないか
- 運用方式設計での変化
- 可観測性の変化
- システム監視からサービス監視へ
- 運用の役割はサービス提供を維持する活動
- 方式設計だけじゃなくて業務設計も重要
- クラウド時代はより業務設計が重要になるよ
- 方式設計の支店もかわるよ
もっと時間かけてじっくり話ききたかった。得にITILのあたり。
波田野さん 「運用エンジニアにとって大事な視点」
- サービス運用現場の正社員としてどうだったかの話を中心に
- 属人化について研究会論文発表してきました
- 属人化は悪ではなく良し悪し
- 特定の顧客企業や技術領域に精通
- 課題 ：IT運用現場人材の役割のモデル化
- IT運用現場人材の役割モデルが不明確
- なぜ日本の運用業務はつらいのか
- ありがちな運用業務とあるべき運用業務
- 人が理解しやすい
- 適切な抽象化
- システムが取り扱いやすい
- 適切な具体化
- 論理的に正しい
- 論理性の確保
- ITで扱う上での当たり前のこと (科学技術と論理てきに向き合うこと) を、当たり前に、愚直に泥臭く徹底的にやっていくしかない
- 人が理解しやすい
- ありがちな運用業務とあるべき運用業務
- 運用能力とは何か
- あるべき運用業務おｗ実現できる能力＝運用能力
- 論理能力
- データで証明できる
- 抽象化能力
- 対象物を目的にああせてモデル化できる
- 具体化能力
- 現場や現実を直視して常に最適化できる
- 上記はめいじてきなのうりょく
- 技術能力 (スキルセット)
- 行有無能力
- 暗黙的な能力とは、「ITで扱う上で当たり前のこと」
- 思考とふるまい (マインドセット)
- 明示的な能力
- 客観的な評価しやすい
- 育成しやすい
- 影響は個人内にとどまる
- 暗黙的な能力
- 客観評価は困難
- 育成も困難
- 組織文化への影響大
- 根性がひん曲がった人を矯正するのは困難
- 自分たちの組織の空気がよければポジティブにフィードバックされるのでは
- 運用エンジニアにとって大事な支店
- ありがちな思考とふるまい
- 業務要求 インプット
- 活動 思考
- アウトプット ふるまい
- ロジックモデルから考えるマインドセット
- アウトカム 実現 <- 運用エンジニアにとって最も大事な視点 アウトカムとは結果、成果という意味
- ありがちな思考とふるまい
- はたのさんのアウトカム
- 運用現場の理想
- サービスの安定
- 業務負荷が平準的
- 運用に対する評価が適正
- 運用エンジニアはアウトカムを実現するために思考し実装し続ける
- 運用現場の理想
- みなさんの運用業務におけるアウトカムは何ですか？
- 例 アウトカム実現に必要なこと
- 運用をサービスデリバリと捉える
- リクエストに対するデリバリの繰り返し
- 運用をサービスデリバリと捉える
- 運用とは
- サービスを継続的にデリバリすること
- 運用業務の本質は事業継続性の実現
- 外部審査はやらない方がいい 理由は (ｒｙ
- 運用設計とは
- 各現場に適した運用のフレームワークを作り込むこと
- 運用設計はなぜ必要か
- 運用現場の理想実現の橋渡しをすること これが運用設計
- 常にシンプル
- 常に見える
- 常に価値を生む
- 黙っていても価値を下げるものをどう下げないか
- 現場の現実と理想は、現場にしかわからない
- 運用設計は運用現場の人が主導権をもたないとなりたたない
- 運用現場が能力をつけていかないと日本の運用現場はもたない
- すごく優秀な人1人おくのが理想
- せめて自分でリスクをとっていける人がいてほしい
- 運用現場の理想実現の橋渡しをすること これが運用設計
- まとめ
- アウトカムを実現するためにどんな思考をするか
- 思考
- 実現
- これらが運用エンジニアにとって大事な2つの視点
- 経営層 顧客 運用要員
- アウトカムを実現するためにどんな思考をするか
- 例 アウトカム実現に必要なこと
- 属人化は悪ではなく良し悪し
- 質疑応答
- あまねさんから
- パネルディスカッションやりたいですね
- ぬるぽから
- アウトカムを実現するための思考ってどうナーチャリングするんですか
- あまねさんから
私の質問に対して上記スライドが出てきて仕込み (サクラ)疑惑を持たれてしまったｗ
沢渡あまねさん 「ライフサイクルマネジメント」
- ssmのキャッチフレーズ「アウトプットしないのは知的な便秘」よいね
- バリウム飲んできたので便秘になりたい
- 勝てる運用者になるために ライフサイクルマネジメント
- 経験職種 IT x 広報
- インターナルコミュニケーションのお仕事に活かしている
- ITILをいかに使いこなすか。ITILを目的にしてはいけない。
- IT業界のフレームワークやITのエンジニアのカルチャーを活用して、組織の課題を解決したい！
- ITエンジニアが正しく活躍できる社会を創りたい！
- これがあまねさんの人生をかけたアウトカム
- ダムはいいぞ
- さわやかはいいぞ
- ITざっくばらん会in磐田主催
- 天竜浜名湖線貸し切りで今週16日にオフする
- エンジニア銭湯
- 番台でLTできるぞ
- 世の中の残念な業務やITシステムはデザイン(設計)で解決しよう
- 利用者や運用者の気合・根性・マナー任せにせず
- ITサービスや業務の「おはよう」から「おやすみ」までを想定してデザイン(設計)する
- ライフサイクルマネジメント (おはようからおやすみまで)
- 何に？
- 業務・サービス
- システム
- データ
- 機器 資材 材料
- 組織 権限
- どんな変化が？
- 新規（おはよう） -> 利用 -> 変更 -> 停止 -> 廃止（おやすみ 永眠）
- 取ったデータは生き物
- あなたがハンバーガーショップの会員サービスを新たに始めるとしましょうか
- 新規 ： 新規に会員証とIDを発行する
- 発行時のオペレーションは？
- 想定しうる問い合わせとその対応は？先にFAQ作っといたほうがいいよね
- ITILでいうところのプロアクティブな運用
- 会員証とIDの名称どうする？早期刺させやすい工夫は？
- 利用 ： ユーザ（利用者）運用者（店員など）その他第三者の利用シーンを想定する
- 操作
- 閲覧 照会
- 出力
- 複製 回覧
- 提示 提出
- 保管 記憶
- 説明
- メンテナンス
- 新規 ： 新規に会員証とIDを発行する
- 何に？
ユーザーの現在地（画面名とか）説明がしやすい創りにしないとね
-
-
- 変更
- 会員情報の変更トリガーおよび変更パターンを想定する
- 姓変更
- 住所変更
- 会員証紛失
- 会員情報の変更トリガーおよび変更パターンを想定する
- 停止
- 下院資格の期限切れ 失効
- 会員の申し出による停止
- 会員情報システムをメンテナンスで計画停止する
- 権限保持する？しない？休職中は？セキュリティポリシーにてらしあわせて
- 物理削除？論理削除？
- IDを再利用する？しない？
- 廃止
- 会員サービスそのものを廃止する
- 個人情報保持する？しない？
- データや記憶媒体をどのように破棄する？
- 周知や問い合わせ対応は？
- 会員サービスそのものを廃止する
- 変更
- ライフサイクルあれこれ
- ITILエンジニアイベントの企画運営
- 企画 -> 周知・拡散 -> 準備 -> 実施 -> 学びの拡散 -> 終了 -> 波及
- ITILエンジニアイベントの企画運営
-
- 行動設計
- 行動をしたくなるよう促す
- 行動を阻害する要員を取り除く
- インターフェース設計
＜画像＞
- スーパーマリオは初期設定の勝利
- 運用業務の価値は相手が決めるもの
- 説明できない仕事は悪気なく軽んじられる
- ライフサイクルマネジメントを実践し、人と組織の継続的な成長を。そして運用の価値向上を！
- 運用者と運用業務の価値をどう上げていくか ブランド・マネジメント
- Be 業務デザイナー！
- 私たちは世界を運用している
沢渡さんの資料が公開されています。
https://docs.google.com/presentation/d/1NWYbLal2AneW9O02NXiaImAUKJaA2aUL84D8904Qhi0/edit?usp=sharing
＜質問タイム＞
- 運用エンジニア 1.0 : オペレーター
- 運用エンジニア 2.0 : 運用の知見を活かして業務デザインに入る
- どちらも価値があru
- クラウドはちゃんと運用できる人にとってはチャンスだ
- イケてるサービスとは
- 営業とか企画とか運用とかの垣根をこえている
- 相互リスペクトがある
- ナレッジマネジメントやブランドマネジメントがうまくいっている
- お互いの専門分野がありながら相互リスペクトがありお互いに興味をもっている
- おにぎりペイについてどう思いますか？
- きちんと運用できる人を巻き込もうよ。
ssmのtogetterはこちら。
資料が追加されたらこちらに添付されるはず。
イベント全体的な感想とか。
- 運用のつらみを愚痴るフェーズは卒業していると思う
- ただしい言語化だいじ
- 運用業務の言語化は波田野さんが第一人者じゃないかと思っている
- 言語化されない{業務,スキル,etc…}は悪意なく軽んじられるという沢渡さんの名言
- ITILについて深堀りしたい あと非機能要求グレードとか
- 今やってる自分の業務は間違っていないという確信を得た
- 運用エンジニア2.0ってDevOpsでは？
- Dev出身じゃなくてOps出身な人がどうスキルを横展開してDevOpsな現場を回しているか知りたいのでディスカッションしましょう
- 要求とスキルセットはだいたいどこも一緒だと思う。極論だけど。さてマインドセットどうする？
- 運用現場にマーケの手法を、マーケの運用にインフラ運用の手法を持ち込もうと試みてるのって、私だけじゃないはず。きっと誰かやってるでしょ？
- 言語化、というかラベリングだいじ。このあたりのエビデンスが欲しい。事例ともいう。