•

みなさまご無沙汰です。 #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を再利用する？しない？
      • 廃止
        •  会員サービスそのものを廃止する
          • 個人情報保持する？しない？
          • データや記憶媒体をどのように破棄する？
          • 周知や問い合わせ対応は？
    • ライフサイクルあれこれ
      • 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な現場を回しているか知りたいのでディスカッションしましょう
    • 要求とスキルセットはだいたいどこも一緒だと思う。極論だけど。さてマインドセットどうする？
    • 運用現場にマーケの手法を、マーケの運用にインフラ運用の手法を持ち込もうと試みてるのって、私だけじゃないはず。きっと誰かやってるでしょ？
    • 言語化、というかラベリングだいじ。このあたりのエビデンスが欲しい。事例ともいう。

•

みなさんこんにちは。大抵の風呂が狭くて足を伸ばせない、1216サイズ以上のユニットバスが欲しい @nullpopopo です。銭湯、いいですね。昔いた職場はあまりにも帰宅できないので、銭湯マップなるものが張り出されていた思い出があります。楽しかったので何ら問題なかったですが。で、あれから約20年後、まさか銭湯で働き方改革について語る場ができるとは思いもよりませんでした。

銭湯でかるたとディスカッション

場所は大崎、百反通りにある金春湯さん。

イベント終了後にひとっ風呂いただきましたが、いいお湯でした。

銭湯にあるかるたとは思えないw #エンジニア銭湯 #銭湯 #大崎 #戸越銀座

nullpopopoさん(@nullpopopo)がシェアした投稿 -


今日のイベントで使うグッズがありました。

エモい #エンジニア銭湯 #大崎 #戸越銀座 #品川区 #銭湯

nullpopopoさん(@nullpopopo)がシェアした投稿 -


エモい。

なぜか顔ハメがあったのでハメてみたなど。

イベントのはじまりはソフトドリンクで乾杯。

アイスブレイク的にはじまった、職場の問題かるた。

7人でやってこれだけとれました。

( ´-｀)｡oO( いつの間にかTwitter検索結果の埋め込みができなくなってたのでこちらで。 )

今日のようすは早速近藤佑子さんがまとめられていました。グラレコできる人が裏山。

個人のお気持ちというか感想

品川区の職員さんが来ていたのでビックリした

  • 五反田バレーの動向には注目していて、そんな最中に #エンジニア銭湯 の話題をキャッチしたので見にきてみた (職員さん)
  • 反11系統のバス路線までは五反田に含めてもらえませんかねー、弊社も五反田っぽい企業と呼ばれたい (ぬるぽ)

LT盛り上がったぞ

  • 角屋さん、エンジニアやりながら家業の銭湯を手伝う。ととのったー
  • 後藤さん、株式会社東京銭湯 って会社があるのか (!)
  • 沢渡さん、銭湯やダムで仕事したっていいじゃない
  • 久保田さん
    • 満員電車の通勤をやめた
    • 飲み会をやめた
    • 情報をクローズドにするのをやめた
    • 「開発」をやめた
    • 時間と場所を縛るのをやめた
    • 1つのキャリアに限定するのをやめた

ディスカッション、熱かったです。「仕事ごっこ」をやめるには、という沢渡さんの投げかけは凄く「それ！それ！」でしたね。いやもう私が仕事でいっちばん相手したくないタイプが「仕事ごっこ」な人なので。違う意見があって自分と反対向いてる人のほうが、お互いに歩み寄るにはどうすればいいだろうってアプローチ取れるんですけど、仕事ごっこしてる人って

  • 会社には在籍したいけど仕事したくない
  • 仕事したくない、というかタイムカード切ってる間は面倒ごとおきてほしくない
  • 自分の意見なんてあるわけがない

だいたいこのあたりに収斂されるので、歩み寄りようがないんですよ。そのくせこういう人は

  • 忙しいフリをするのが仕事
  • つらいことを我慢するのが仕事だと信じて疑わない
    • 会社にいるのはつらいことなのだ、だから私は仕事しているんだ
    • オマエもつらい思いしろ、サボるのは言語道断

というメンタリティなので、そもそもの世界観が違うんですね。なんでこんな仕事ごっこしてる人がいるかというと

  • 誰でもできる仕事しかしていない、させてもらえない、そもそもできないということが自分でわかっている(コンプレックスに思っている)
    • ゆえに他者との差別化がしにくい
    • 他者との"ちょっとの差"を"ものすごく"気にする
  • 外でやっていけるとはサラサラ思っていない
    • ゆえに社内政治に長けているなどで差別化を図ろうとする
  • 結果よりもプロセス重視
    • 私はプロセスを守っているんだ、だから結果が出ないのは会社の責任だ、と思っている

というような文化に染まっているからなんだと思っています。なので、成果出すから自由にさせろという単純明快な欲求がある人とは根本的に合わなくて、仕事してる人にとってのいい会社と仕事ごっこしてる人にとってのいい会社って違うんだろうなあ、というお気持ち。で、私にとってのいい会社って、

許可を求めるな、謝罪せよ

な世界観だと思うのですよね。だって、仕事ごっこしてる人って「謝ったら負け」って思ってるでしょ？と、そんなことを思い出しながら家路についたのでした。あー楽しかった。またこういう有意義な集まりに参加してみたいです。

 

•

Linux UNIXの自分のアカウントでsudoが使えるかどうかは、

[oreore@marina ~]$ sudo :

あなたはシステム管理者から通常の講習を受けたはずです。
これは通常、以下の3点に要約されます:

    #1) 他人のプライバシーを尊重すること。
    #2) タイプする前に考えること。
    #3) 大いなる力には大いなる責任が伴うこと。

[sudo] oreore のパスワード:

[oreore@marina ~]$ echo $?
124

このように、 /etc/sudoers の Defaults timestamp_timeout の値(分)を超えるまで待つか、何かしらのコマンドを実行して返り値を求めればよいです。が、自動実行しているスクリプトでこれをやろうとすると、

  • bashの内部コマンドなどで返り値がうまく取れない
  • sudoのパスワード待ち(対話コマンド)で待たされる

という問題を解決したくなるのが人情ってなもの。プログラムの中で自身のアカウントがNOPASSWDでsudoできるかどうかのチェックロジックを入れたいときに、このようなちょい面倒なハードルを超えなければならないのです。大きく面倒というわけじゃないですけど。

/etc/sudoers を短く編集するという手もあるじゃないかという声も聞こえてきますけど、それだと手オペでsudoするときの利便性が損なわれてしまいかねないので、システム全体の利便性を損ねずにプログラムの中だけで解決したいですよね？

…続きを読む →

•

「みんなが知っておくべき運用設計のノウハウ」、Amazonですすめられたので、Kindle版が250円と安価だったので試しに読んでみました。kindle unlimitedですと読み放題ですが、そうでなくても250円で運用設計の勘所を抑えられるので激安ですね。

…続きを読む →