「業務運用ってなあに！？」～『運用☆ちゃん』読書しながら会#002 

4月 1日 @ 21:30 ～ 22:30 主催: 沢渡 あまね

資料

• インフラ勉強会/「業務運用」をハズしちゃダメ！Incident 006 #運用ちゃん - esa-pages.io 
  • 4月1日、CodeIQサイト緊急メンテナンスにつき、暫定サイトを使って行います
• 音声データ 

講演

自己紹介

• 業務側IT調達・企画
• その後 SIer で認証基盤システム立ち上げから運用、サービスマネージャー

運用ちゃん#6

5話では運用設計の話

• 業務運用
  • 今日はこれ
• システム(基盤)運用
  • 監視、バックアップ etc
  • 前回はこれ
• ヘルプデスク・サービスデスク
• 運用統制
  • 大規模運用では、全体のコントロール・顧客や社内向け報告などを行う

業務運用って何?

「業務運用」って言葉使ってる?

• 「サービス運用」というところも

今日の狙い

• インフラエンジニアの頭の中に「業務運用を持ってほしい
• 「業務運用」という考え方がないところも
  • 意識付け・引き出しを持てるようにしてほしい

業務運用は何をするのか?

• 運用業務全体の計画
  • 年間・月次・週次・日時運用業務スケジュールとか
• 帳票データ抽出・提供
  • ユーザ要望に応じたデータ提供
• データメンテナンス
• ユーザへの周知
  • システム停止・復旧予定などのコミュニケーションチャネルを作って周知したり
• 業務イベント対応
  • 組織移動とか組織統廃合への対応

業務運用 = 業務とシステムの橋渡し役

• お客さん・利用者gシステムを使って業務を回していくために必要なこと
• リリース間際とかになってからマスタ更新誰がやるの、みたいなことになったりしてしまう。
  • 気の利いた人がたまたまやってる、とか
  • 本来ベンダや情シスがやる作業じゃないのに、とか
• 要件定義の段階からこれは業務運用でまわしていくとユーザと話をして決めていく。
  • チャネルを作って話をしていくこと。最悪でも結合試験段階では決めていかないと、人が足りなかったり予算が付かなかったりして取りこぼしてしまう恐れがある。

主な業務運用項目

大きな現場だと「運用統制」機能があったりして、そこに含まれる項目もある。

1. 運用スケジュール管理

   • いつ何をするかスケジュールを決める...神様が決めてくれるわけではない。
   • 作業項目の改廃: もうやらなくていい、新しい作業が必要だ、会社の人数が増えたので利用者側にお願いを出す、など。定期的な棚卸しが必要。働き方改革的な文脈でも必要。どんな業務でも年1回は棚卸しが必要、なぜなら環境は変化するから。
   • スケジュールの見直し、作業項目改廃をするために: スケジュール中に、この日は運用スケジュール見直し、というのを入れておく。
   • 運用業務を一覧化する・ドキュメント化するというのが必要 (業務一覧が出てこない闇…最初に話を聞いて書き出す)。業務項目が親→マニュアルが子、言うとやっていることになるので言うのを嫌がられたりすることがあるのでやり方は考えないと行けない。でも書き出さないとコストの根拠を提示できない。予算を要求できない。出した上で、自動化するとか検討。
   • 暗黙知を出した人にインセンティブが必要。ナレッジ共有を人事評価項目に入れてやった人が評価される仕組みを作るとか。
   • 定期運用項目がなかなか出てこない…カレンダーを見ながらこの頃の作業を出す。年間スケジュール把握は重要。1年間通してみていく。ITライフサイクルマネジメント、繁忙期・閑散期とかを見た上で作業スケジュールや休みの予定などを見ていく。
   • 証明書更新作業、保守契約の更新…ITIL構成管理にも関わる。
   • 普段の業務に何が必要なのか出してくれない人…でもそれだと新しい価値を出せない。いつまでたってもオペレータなのか? 自分だけでも書き出していく。
   • 運用項目一覧、スケジュール表、実施チェックリストなどがアウトプット。

2. データ／マスタメンテナンス

   • 顧客やユーザに要望に応じて必要なデータを抽出したり、データのマスタ等を修正したり(取引先の社名変更など)、データにパッチ当てたり
   • 変更画面がなかったとか、変更権限の定義がなかった、等ありがち。

3. ユーザ情報管理／権限管理

   • 2と関連して。
   • 権限付与剥奪: グループを作ったり、特権(管理者権限等)の管理をしたり。
   • 兼務を含む権限付与とか結構面倒。ユーザ管理は外部監査が入ったりする会社では大変。出向者の取り扱いとかも。
   • 棚卸しの自動化が必要だけどその前に業務ルールの整備が必要。申請が上がらずに退職してたり。
   • 特権ID: root/admin, ヘルプデスク権限も重要(権限がないとそもそもヘルプできない…いろんな琴に答えられないといけないので)。要件定義の段階で画面ごとに定義しておかないと抜ける。システム作りとかクラウドサービス選定とかで業務運用は重要
   • 同姓同名の罠

4. 構成管理／文書管理

   • ITILでも管理項目の一つ。監査やセキュリティの文脈でも。ソフトウェアやミドルウェアのバージョン管理など、要求は年々厳しくなってきている。
   • 証明書やソフトウェアライセンスの管理: 過払い、期限切れなど。様々なサービス上の問題につながる
   • 既存運用の追加や変更に対してアップデートしないと、いつまでたっても業務に追いつかない神Excelがついて回ってしまう。
   • ITILでいうリリース管理・変更管理と表裏一体。ちゃんとやれている現場の場合、リリース時に変更管理影響やユーザが使っているWebの変更への影響度を判定して、ヘルプデスク側でドキュメント作ってもらったりユーザへの周知を計画、そこまで含めてリリース判定。リリースに先んじて資材を整えておく。
   • 阿吽の呼吸で? 上手くいっているときはいいけど、一部をシステム子会社に委託とかになると美味く回らなくなったり…
   • 理想は都度ドキュメントをアップデートすること、だけど、常にできるわけではない。そのためにも決める。運用スケジュール上3ヶ月に1回はやるとか。業務運用統制係にイベントキックしてもらうとか。マネジメント…個人のスキルやメンタリティに依存しないやり方でやれるようにすること。チームで管理して、安心して忘れられる。相違仕組み作りが必要。そこが運用管理する人の強みになる。
   • やるべきことがあったらすぐインシデントチケットを切ってしまう。切ってしまえば後は運用統制チームが裁いてくれる。月次・週次のミーティングで必然的に議題に挙げる。

5. インシデント対応／問題対応

   • インシデント: 通常の業務を妨げる何か。トラブル対応を含む。
   • 事前にこういうユーザー対応しておいた方がいいんじゃね？というのをインシデントにするのもアリ。「したいこと」をインシデントとして扱うというのも一つの手。業務の手を一度止めて対応をするという意味で。
   • 障害対応だけでなく、想定外のものはインシデントとして扱ってしまって良い。業務一覧に載っていないものはインシデントとしてもよいかも。バランスはチーム内で意識あわせをしていく。最初は困ったことはリーダーに声かけてもらってインシデントにする市内を定義していくとか。
   • インシデントを二度と発生させないための高級対応 → 問題対応(ITIL)
   • インシデント対応と問題対応が分かれていないと、暫定対応がいつの間にか高級対応になる。運用項目はだんだん増えていってしまうので、"マネジメント"が必要。インシデントは目先の対応・問題対応は未来の対応。
   • インシデントと問題を切り分けて考えること。切り分けていなくてあたふたしている現場はいっぱいある。それができるだけでも生産性は上がる。(ずーっと暫定対応し続けて疲弊してしまう。トラブルから問題を出して対策していく。きちんと自らノウハウ化しないといつまでもあたふた。過去のインシデントを元にしたノウハウがある人は重宝がられるし、要件定義段階でそういうノウハウをフィードバックしていったりできるようになる。)

6. ジョブメンテナンス

   • 夜間バッチ等。ユーザ数・トラフィック量・ストレージやメモリ状況などを見ながら変更していく。ジョブ管理・再設計、新規サービス構築時やクラウド利用時、社内サービス組合せなど、考える上で重要。
   • 4/1とか人事異動が大量にあるときとかは、認証基盤などでバッチ処理が終わらなかったり。バッチ処理時間とかは監視設計で定義して測っておくのがよい。監視しておいてどうするか。データガベージしたり、プロビジョニングタイミングを変えたり。

7. リリース対応

   • 忙がしいタイミングでリリースしない／させないって、管理も大事。リリースのためのシステムメンテをいつやるかといった計画も。
   • そういった意識付けを顧客に対してもしていく。
   • 海外を含めてみていると、定期メンテをいつやるかとかが難しい。中近東とか日曜が休みじゃないところも。サービスの性質に寄りけり。

8. 調達業務／課金請求

   • 機器とかライセンス、顧客への費用請求など
   • データ抽出業務があるなら、専用のソフトを買ってやったり。
   • 「クラウド時代の運用者の歩き方」をこのあと書く。クラウドのいいところ…調達が楽になる。サービスだと経費化。お金払うのを購買部門を経由せずに決められる。調達は時間かかるし面倒。現場の裁量で回せる範囲が増える。

9. イベント対応

   • イベント? 基盤運用的にはjp1とかに見られがちだけど、業務運用ではもっと広義。組織変更対応やオフィスのレイアウト変更対応など。会社統廃合なんかも。業務としてのイベントを事前に察知してユーザへの通知や必要な資材、システム側への変更などを考えていく。

10. 訓練／トレーニング

    • 災害やセキュリティインシデント対応の教育やトレーニング、避難訓練なんかも。
    • 客によっては「年に1回は必ずやってください」という指示があって、結果をドキュメントで報告するということもある。
    • バックアップ・スタンバイ環境等用意しておいても、訓練しておかないと使えない。例: 航空機会社システムトラブル時の某空港の「紙対応」

11. コミュニケーション管理

    • 周知をどうするか、中の人、運用者同士、業務統制、フロントエンド。
    • コミュニケーションを何を使ってやるか。コミュニケーションの設計と実施。中であれば slack etc, 顧客向けにはメンテの連絡などの定時手段など。(ユーザにヘルプデスクの存在が知られていないなんてことも)

12. サービス報告

    • 月次・週次等の運用状況や課題の報告
    • サービスの利用状況（どこからどこへアクセスが多かったとか）、サービスレベルで決めた内容に対する状況、インシデントの発生/対応状況などなど。
    • メモリやストレージの使用状況や変化、運用者の勤務時間も大事。

まとめ

自分やっている仕事がわからない・説明できないにならないように。業務運用という箱を説明できる…自分に・これから入ってくる人に・お客様に。

参考書籍

• Amazon.co.jp： みんなが知っておくべき運用設計のノウハウ eBook: JBSテクノロジー株式会社: Kindleストア 
  • 全体的な項目が網羅されてる
  • 業務運用はちょっとよわめ
  • JBSTにはプロモ用の紙版があるそうだ
    • 紙があるとお客さんや運用メンバと意識あわせがしやすい
• わかばちゃんと学ぶ Googleアナリティクス〈アクセス解析・Webマーケティング入門〉 | 湊川 あい |本 | 通販 | Amazon 
  • GA基礎から
  • お客さんがやる業務運用ってこういうことだというのを示していく本
• 東京駅 丸善丸の内本店(OAZO)のサイエンスラボで沢渡さんのおすすめ本の展開があります。4/2から4月末まで

参加者の声

(Discord 上の発言で、なにか取り上げたいものがありましたら記載お願いします)

• 見えてないものは改善しようとも思わない

• 業務一覧が出てこない闇

• マニュアルがアップデートされてない 以前に 業務項目がアップデートされてなかった系

• 一人しかできない秘伝の作業、思っているより結構ある

• 権限管理のベネッセの件は、マジでSESの闇の部分が世間にインパクトを与えてしまった感しかない。

• 最近よく「人は忘れるから忘れてもいいようにしろ」言ってるわ

• 人は忘れるし、間違う生き物ですから！！

Q & A

(Discord 上に質問が流れたらピックアップお願いします)

• Q.既存文書は都度Updateするのが望ましいけど、できないときは、既存のマニュアルを赤入れしといて、3ヶ月に1回とかでUpdateするとかしてますが、アリですか？
  • A.ありだと思います。理想論は書き換えですが、実態で難しいのは当然だと思います。こういう所をコントロールするのがマネジメントだと思います。