20231006登壇資料.pdf

Transcript

1. ひとりServiceNowアドミンの アップグレードの経験談 株式会社アカツキ　IT Service部　　宮越　信吾
2. 簡単に自己紹介 • ServiceNow歴 ◦ 2015年頃〜 ▪ 初めて触った ▪ Genevaだった記憶がある ▪ 当時はSIerとして ◦ 2018年頃から ▪ ユーザ企業に所属 ▪ ServiceNowの管理者 ▪ Londonくらい • 最近の趣味 ◦ 音楽鑑賞(レコードで聴いてます ) ▪ 趣味はアナログ ▪ 仕事はデジタル
3. 前職 現職
4. 前職 現職 この間のアップグレードを一人でやっていた
5. 何度やってもアップグレードは大変
6. 何が大変なのか • 画面の表示や動きが変わることがある ◦ UIの変更 ◦ Business RuleやScript Include, WorkflowなどOOTBのロジック変更 ▪ 破壊的変更だとより大変 • Knowledge v2からv3になったときはとても大変だった (と聞きました) • To Reviewの対応 ◦ カスタマイズが多いと対応件数も膨大 ◦ カスタマイズしていなくても発生したりする ◦ 経緯が不明なカスタマイズがあると対応に苦慮する • テスト ◦ 結局は人力でテストすることになる ◦ 網羅的に確認していくと手間と時間と根気が必要になる 全部ひとりでやっているのでそりゃ大変です
7. 何が大変なのか • 画面の表示や動きが変わることがある ◦ UIの変更 ◦ Business RuleやScript Include, WorkflowなどOOTBのロジック変更 ▪ 破壊的変更だとより大変 • Knowledge v2からv3になったときはとても大変だった (と聞きました) • To Reviewの対応 ◦ カスタマイズが多いと対応件数も膨大 ◦ カスタマイズしていなくても発生したりする ◦ 経緯が不明なカスタマイズがあると対応に苦慮する • テスト ◦ 結局は人力でテストすることになる ◦ 網羅的に確認していくと手間と時間と根気が必要になる 全部ひとりでやっているのでそりゃ大変です やること いろいろ ありますよね
8. 進め方のスケジュール感 メジャーバージョンアップ月間として対応を最優先 管理も開発も一人だと自分のタイミングでスケジュールできるので調整は楽 バ ッ フ ァ テ ス ト ／ 修 正
9. アップグレードでの変更に対する考え方 • 「大前提」としてServiceNowが意志を持ってOOTBを変更している ◦ 最新機能の実装 ◦ 機能エンハンス ◦ セキュリティ向上 • まずは「変更を受け入れる」ことを考える ◦ 現状の動作に固執しない ◦ どうしても受け入れられない点だけ洗い出しておく ▪ 可能ならば変更を受け入れた上で再修正する ◦ OOTBを受けれいることは未来への投資 ▪ 非推奨や廃止になる機能はたくさんある • 代替は事前に用意されている ▪ 既存の画面やスクリプトに新機能が組み込まれることもある • 受け入れないといつまでも新機能の恩恵にあずかることはできない 「どう対応するか」を相談できない代わりに「判断できる」ため思想は貫ける
10. Utahでの廃止情報(抜粋) 生まれては消えていくWorkspaceたち。。。
11. • 変更の内容を理解する ◦ リリースノート読む ◦ 全量把握は大変なので大きなトピックなどが中心になりがち • 愚直にリグレッションテストをやる ◦ UIの変更は検知できる ◦ ScriptやWorkflowについてもある程度検知できる ▪ 検知できない変更は運用上問題ないものとしてスルーしている ◦ ACLの変更についてadminでは検知できないのが厄介 ▪ impersonateでRequesterの気持ちになってみる 変更された動作の検知をどうやっているか
12. 変更された動作の検知をどうやっているか • 変更の内容を理解する ◦ リリースノート読む ◦ 全量把握は大変なので大きなトピックなどが中心になりがち • 愚直にリグレッションテストをやる ◦ UIの変更は検知できる ◦ ScriptやWorkflowについてもある程度検知できる ▪ 検知できない変更は運用上問題ないものとしてスルーしている ◦ ACLの変更についてadminでは検知できないのが厄介 ▪ impersonateでRequesterの気持ちになってみる ATFを使ったテストの自動化など取り組める余地はあると考えつつも。。。 経験者の方や有識者の方のお話聞きたいです！ 人力で がんばる
13. To Reviewへの対応 • 基本的にはRevert to Base Systemをやっている ◦ アップグレードしながら徐々に OOTBとの乖離を減らしていく ▪ 導入時の要件通りであり続ける必要は無い (はず) ◦ 必要であればUpdate Setを作成してRevert後に再修正している • Resolve Conflictsで部分的な取り込みも実施している ◦ Business RuleなどInactiveにする変更を行っていた場合 ▪ Resolve ConflictsでConditionとScriptだけ取り込むなど 作業ログをチケットに残しておくことで当時のいきさつを確認できるので 経緯を覚えていなくて「詰む」ことはほぼない(ログ残すの大切) OOTBに変更を加えない実装ができれば大変さは減るはず
14. UtahへアップグレードしたあとのUpgrade Monitor • To Review: 49件 ◦ Disposition別内訳 ▪ Skipped: 12件 ▪ Skipped Error: 36件 ▪ Skipped Manual: 1件 • Tokyo(3月)~Utah(9月)で主にやったこと ◦ CMDBの構築 ▪ PC端末のDB化 ◦ SAMの拡充 ▪ SaaS管理 ◦ Service Catalogの追加 ▪ Catalog Builderを使って 市民開発的な手法を導入 ▪ 別部門への横展開準備
15. 実装方針 ServiceNow社の修正と我々のカスタマイズがコンフリクトすることでTo Reviewが発生 OOTBの意味や思想を理解せずに表層だけでカスタマイズすると思想とズレていく • 極力OOTBを変更しない方針 ◦ View ▪ 新規でViewを作成してカスタマイズ。OOTBはそのまま残す • OOTBを変更するしかないViewは許容(workspaceやVTBなどの決め打ちもの) ◦ Flow/Workflow/Business Rule ▪ OOTBからコピーしOOTBはInactiveにする ▪ コピーした新規Workflowでカスタマイズ • 変更不可避なものは仕方ない ◦ 安易にカスタマイズせずに「本当にカスタマイズが必要か」を最後まで考える ▪ 手段として代替できるものはないか ▪ そもそもカスタマイズが必要な要件なのか アップグレードとの闘いは既に始まっている
16. 1. 導入プロジェクト開始時の要件出し a. 既存システム運用中で ServiceNow未経験だと既存システムをベースとした UI/UXや機能が出てきがち (カスタマイズ多) 2. 運用を開始した後の最初のアップグレード a. ServiceNowの上で運用を開始しているので UI/UXや癖、やれることの違いなどを徐々に実感 3. 2回目以降のアップグレード a. 少なくとも1年以上は運用している b. ServiceNowの世界にも慣れてきて、前システムへのこだわりや考え方よりも「 ServiceNowでどうするか」 徐々にServiceNowの世界観に慣れていくはず
17. 最近の困った
18. • ServiceNow本体のアップグレードも大変 • 最近はPluginも高頻度で更新されているので対応が必要 ◦ 着実にPluginが増えている ▪ Employee Service Center(ESC) ▪ Software Asset Management(SAM) ▪ 各種Workspace ◦ Pluginが他のPluginに依存することも増えている ▪ 1:Nで依存が多いパターン ▪ マトリョーシカのように依存が依存を呼ぶパターン ◦ Pluginをアップデートするがバグを内包しているパターン ▪ バグを内包したバージョンは避けたいが、依存関係に含まれるため逃げられないことも ServiceNow本体だけではなく、Pluginまで対応が必要になるので大変 中には振る舞いに致命的な影響を与えるアップデートもあるので要注意 Pluginが強敵になりつつある
19. Pluginが他のPluginに依存しているパターン • 依存関係41個。やり過ぎでは？(また増えた) • このPluginの中にバグを内包している Pluginがある ◦ 最新バージョンへアップデートするとSubFlowが壊れる ▪ 次頁にて。お楽しみに。 • UtahにするとこのPluginをアップデートしないと壊れる ◦ Workspaceのメニューが一部非表示になる ◦ 破壊的変更が入ったので一部処理がエラーになる
20. プラグインをアップデートして壊れたパターン • Actionが見つからず動かなくなった例 • SubFlowがRead-Only ◦ ユーザ側では変更できないもの • 本番でも絶賛壊れ中 ◦ サポートに問い合わせているが未だ解決せず
21. まとめ • 影響範囲の確認や対応など作業が広範に及ぶのでたいへん ◦ 最近だとpluginも対応必須なので対応範囲がより広がった • ひとりでやっているとタイミング調整や対応方針は決めやすい ◦ 対応方法も自己判断と作業で完結できる ◦ 困ったときにはサポートに問い合わせることもできる • OOTBが壊れたり対応方法が不明なTo Reviewが発生することもある ◦ サポートとのコミュニケーションが発生するので作業量がマシマシ ◦ 解決できる返信がなかなか来ないのでいつまでもアップグレードが完了できない • ServiceNowがプラットフォームとして大きくなりすぎて ◦ ひとりで見るのも限界が近いのでは説 ◦ サポートもカバーしきれていない説 ご清聴ありがとうございました。