Enterprise Blue Ocean ◮

神谷町RPAブログ

  • [特集] Blue Prism の製品概要がよくわかるWebページ動画取材記事
  • [特集] Blue Prism DX にある、Blue Prismの部品一覧はこちら
  • [特集] Blue Prism でExcelを操作する記事はこちら
  • [特集] Blue Prism のベストプラクティス記事はこちら
  • Blue PrismのQ&Aを掲示板(teratail)でやりませんか?

Blue Prism World London 2019でのアップグレードに関するお話

どもども。「ジャナイホー」です。

前々回、Learning Sessionという小ネタステージを1つ紹介しました(↓)。

www.ebocean.work

 

今回は、「アップグレード」についてのステージの内容をご紹介します。

皆様の環境に置かれましても、Blue Prismをアップグレードしたい、しなくてはならない、ということがあるかと存じます。

ま、当たり前っちゃぁ当たり前のことばかりですが、少しは参考になればと思います。

 

f:id:EnterpriseBlueOcean:20190413025258j:plain

UKのレジェンドコンサルタント、「マスター カーター」が語ります。

傍らにいるのは、複数のユーザ企業で「Head of RPA」として組織を率いてRPAチームをスケールさせてきた経歴を持つ、Customer SuccessのJaneでございます。

 

先ず、

アップグレードを始める前の検討事項について

です。

  1. Blue Prismのお客様であれば、最新バージョンのBlue Prismソフトウェアは、無償で手に入れられますが、アップグレード作業に伴う作業は、工数と時間がかかります。
    「コストがかからない、簡単な作業」ではない、ことを認識しておく必要があります。
  2. アップグレードと同時に色々な変更を盛り込まないようにしましょう。
    (変更点は小さければ小さいほど良いです。)
    必要な変更や新しいことへのチャレンジは、アップグレード作業が正常に完了した後に回すようにします。
  3. アップグレードは、潜在的な問題を明らかにしてしまったりします。
    特に、
      適切でない設計で実装されたソリューション
      良くない導入方法論(導入手順)
      品質の低い開発
      非効率なサポート体系
    などなどは、
    アップグレード作業によって自然と治るものではありません。
    むしろ問題を顕在化させることがあり得ますので、覚悟して下さい。

作業時の注意点

  • 必ず、すべてのリリースノートを熟読し、影響範囲をしっかりと把握すること
  • v5.x から v6.xへアップグレードする場合の、技術的な注意点は、以下。
    (1) Login Agent、.Net Framework、SQL Serverは、再インストールもしくはアップグレード作業がそれぞれ必要
    (2) 日付書式の仕様変更があるので、その対応が必要
    (3) 論理アクセスモデルが変更になるので、ロールと許可の設定に変更が発生する
    (4) マルチチーム環境が利用可能になるので、運用や設定の変更作業が必要
  • Blue Prism Professional Services部門の「アップグレード アドバイザリー サービス」が存在するので、利用可否を検討してみる
    (アップグレード作業計画のレビューを行うサービスです)
    (環境の規模に依存しますが、大体、5~10人日程度です)

アップグレード作業が成功している例の共通点

  • ビジネス部門とIT部門が連携して計画・作業していること
  • 適切な方法論とベストプラクティスに沿っていること
  • リリース管理が適切に行われていること
  • テストアプローチが策定され、注意深くレビューされていること
  • リスク緩和・低減策が練られていること
  • 適切なしっかりとした計画が立てられていること

 

【シナリオ例】

比較的高頻度で採られる、アップグレード作業のシナリオの例とそれぞれのメリット/デメリットを紹介します。

シナリオ例(1)「完全に新しいインフラ環境を用意する」

メリット

  • すべてを新しく始めることができる。過去のものは過去のものとすることができる
  • 最新かつより高スペックのインフラ環境を手に入れることが出来る
  • 古い環境は、アップグレード作業中も、アップグレード作業完了後も、引き続き利用可能なまま残しておくことが出来る

デメリット

  • それまでの履歴情報や監査ログはすべて古い環境にのみ残されるので、言ってみればアーカイブされるのと同じことになる
  • すべての環境設定を新しい環境に正確に移設しきることが出来ないリスクがある
  • ユーザアカウント情報など、移行が出来ないデータについて、新しい環境で再作成するなどの作業工数が発生する
  • しばらくは並行して古い環境を稼働させておく必要がある場合がある
シナリオ例(2)「DBのバックアップから新しい環境へリストアする」

メリット

  • 最新かつより高スペックのインフラ環境を手に入れることが出来る
  • 環境設定の移行漏れのリスクが無い
  • それまでの履歴情報や監査ログは引き続き利用可能
  • 古い環境は、アップグレード作業中も、アップグレード作業完了後も、引き続き利用可能なまま残しておくことが出来る

デメリット

  • DBのサイズは大きいまま
  • ごみデータ、不要なデータが残ったままになる
  • しばらくは並行して古い環境を稼働させておく必要がある場合がある
シナリオ例(3)「既存のテスト環境やDR環境などを間借りして検証作業を行い、検証完了後に、一気に差し替える」

メリット

  • 追加のハードウェアインフラ環境を用意するコストがかからない
  • データ移行作業が不要で、データの移行漏れなどに依る損失が無い
  • 古い環境は、アップグレード検証中も、引き続き利用可能

デメリット

  • アップグレード検証中は、本来のそのインフラ環境の目的のテスト環境やDR環境を潰すことになる
  • 必要な変更を適切に管理、適用していくことが必要であるが、得てして煩雑である
  • サービスを提供、維持するのに工数がかかる
  • 検証完了後、本番環境をアップグレードする際には、サービスを停止し、一気にやり切る必要がある

【まとめ】

 アップグレード作業に伴う作業は、工数と時間がかかります。

しっかりとした計画を立て、コンティンジェンシープランを練り、ロールバック手順を再確認しましょう。

 

ジャナイホーによるLondonレポートは以上です。