今回はRPAの障害発生時に調査方法が分からないから詳しい人に頼るしかない方や、調査方法のコツを知らなくて手探りで調査をして中々原因にたどり着く事ができないという方向けの記事となっています。
原因にたどり着ける人は何故それができるのかを説明していきます。できる人が行っているコツやノウハウを知れば、システムにそこまで詳しくなくても難易度の高い障害以外は原因特定までたどり着く事が可能だと思います。
障害は「モノ・ヒト・コト」起因で発生するものがあり、実際にシステムを使っている側の方が障害の原因に早く辿り付く障害パターンも存在します。コツを知り、システム担当者-業務担当者間で協力して障害に対処できる現場は障害解決速度が早いです。この記事を見て調査協力できるようになったり、自身の障害対応レベルをあげていく事に繋がったりして貰えればと思います。
【目次】
障害発生から対応までの基本的な流れ
まず、障害発生からの基本的な流れを説明します。障害は発生直後に、調査や業務に影響を出さないように一次対応を行います。その後、原因を調べて対策を検討及び対策実施して事象改善されれば完了です。今回は調査から対策実施までを中心に説明していきます。再発防止策も気になる方は最後の参考サイト一覧にリンクを貼っておくので、リンク先の詳細情報をみて頂ければと思います。
障害が起きる前の事前準備について
障害の調査や対処ができる人は、自身が関わるシステム関連の下記記載の事について事前に調べて整理しています。自身が関わった事のないシステムの保守・運用担当になった時に下記が分かっていないと対処が遅れるため、障害に備えて事前に把握しています。
<最低限必要な事>
①関連システムと確認すべきログの場所と見方を把握
②関係者や業務への影響を把握
関連システムと確認すべきログの場所と見方を把握
下記は一例ですが、どのようなインフラ(パソコンやサーバー、ネットワーク)が関連し、どのような流れでデータのやり取りがされているかを把握します。これを把握している事によって、影響範囲を特定可能にします。障害調査には問題が起きている状態とログに書かれている内容から原因を探る事が多いです。
問題が起きている状態とは操作しているパソコン上でエラーが起きているなら、その時のパソコンの画面や起動中のアプリケーション等の状態の事を指します。システムは異常時にエラーである事を調査可能にするためにログ(文字)に出力しています。ログに出力されない障害もありますが、「まず状態確認とログを見る」が基本的な対応方法であるため、状態に加えログが出力されている場所と確認方法を事前に把握します。
業務担当者の方は、パソコン側の概要知識と確認すべきログの場所と見方だけ把握していれば十分だと思います。これから詳細説明していきますが、業務担当者で実際に修正に関わっていない人は「そんなことをやっているだな」感覚で見て貰えればと思います。システム担当者は自身が関わる部分は全て把握しておく事をお勧めします。
関係者や業務への影響を把握
障害が起きた時は、業務担当者や複数のシステム管理担当者と連携して対処する事が求められる事があるため、誰に連絡を取れば良いか把握を行います。また、どれくらい影響が出るもので、いつまでに復旧しないといけないのか、業務への影響も把握します。これを把握する事で、一次対応をどう進めていくか適切に対処する事ができます。業務担当者は急いで対処しないと大変な事になると思っているのに、システム担当者はゆっくり対処しても問題ないと思っていると温度感の違いによって、対処に失敗してしまう事があるためです。
お互いの認識があっているか確認ができていない場合は、障害前に確認を行いましょう。本来はRPA化を検討する際に障害時にどうするかの認識はあわせておくべきです。
業務担当者とシステム側でこのようなサービスレベルの認識合わせをする項目は復旧優先度以外にも存在します。詳細を知りたい方は下記非機能要求グレードを見ると何を気にしないといけないのか把握できます。システム担当者は必ず知っておいたほうが良いです。
最低限抑えるべき事を説明しましたが、障害対応レベルを更に向上させるためには下記のような事を更に行います。習得に時間が掛かるためシステム担当者向けです。業務担当者の方は「ここまでやると更に詳細まで調査できるのか」と流し読みして貰えればと思います。
<障害対応レベルアップに必要な事>
①関連システムとの通信や連携の流れと技術を知る
②事例と対処の例を知る、経験する
関連システムとの通信や連携の流れと技術を知る
関連システムとログの場所だけではなく、更にどのように連携されているのか、どんな仕組みなのかを知る事で、ログに書かれているエラーメッセージをインターネットで検索して対処が見つからない場合でも自身で原因を調査して対応を進める事ができます。第一段階は流れを知る事です。その後パソコン側を中心に仕組みの概要を知り、最後に詳細を理解していくと良いです。そうする事で障害原因がパソコンから見て外部にある問題である事に気づけたり、どこで問題が起きているのかまで特定可能になります。仕組み的に考えておそらくこういう問題が起きているだろうという予測もできます。かなり詳細まで把握していくと頭の中でトレース(追跡)して、異常が起きそうな所を特定するような事ができるようになります。幅広い基礎知識が前提として必要になるためITパスポートや基本情報技術者の学習をすることで基礎部分を理解できるようになります。
事例と対処の例を知る、経験する
関わるシステム障害の事例を知る事で、同じ事象であればすぐに原因まで辿り着き、類似事象である場合はその事に気づく事ができます。UiPathであれば、コミュニティフォーラムに障害事例と対処の情報が大量に存在しています。一通り目を通すと問題解決までの思考力がかなり向上します。また、障害を未然に防ぐ対策力もあげる事ができます。
調査、情報収集及び一次対応
障害が起きたら、事象と影響を確認して業務に極力影響を出さないように一次対応を実施します。一次対応は発生した時に「どうしよう」と考えるのではなく、「このシステムが止まったらこういう対処をしよう」「この処理で止まったらこういう対処をしよう」と予め決めておかないと一次対応が求められる場合に、誤った判断や対処をしてしまいます。このような事にならないように、事前に方針や手順を決めておきましょう。細かく決めすぎると作成に時間が掛かるため、障害時に業務影響出さないレベルの粒度を考えて作成しましょう。
過去発生した障害の事象と対応結果を障害一覧に残しておく事も非常に重要です。その一覧があれば同じ障害が起きた際に、過去起きていないか一覧を検索し、対処方法も残しておけば、すぐに対処する事が可能になります。担当者が会社を休んでいない時もどのような時にどう対処するか他の人が分かるようにしておく事で対処を進める事や過去の障害傾向から同じ障害を起こさないようにするための対策を検討する事もできます。
先ほど説明している通りに状態を後で確認できるようにしておく事も大事です。RPAではエラー発生時の画面全体をキャプチャで取得しておくと、原因特定に役に立ちます。RPAのプログラム内でエラーが起きたらキャプチャ取得まで自動でするように作っておくと良いのですが、重要情報がキャプチャに移り込む可能性がある業務に対しては、キャプチャ取得を自動でしない作りにあえてしているものもあるため、自動取得できていないようであれば、取得できる人がしておきましょう。調査依頼する時にキャプチャと対象ログを一緒に送ってあげると原因に早く辿り着けます。
UiPath、Windowsのログの出力場所
UiPathのログは規定を修正していなければ、「%LocalAppData%\UiPath\Logs」に出力されます。%%で囲われているものは環境変数といって、パソコンにログインしているユーザ等によって値が変わるものに対応するためのものです。この%%のまま検索して選択するとログが保存されている場所に移動できます。移動先の「Execution.log」が実行された時に出力されるログです。
実際に開いてみると下記の情報が出力されています。エラーの場合はErrorとしてログが出力されます。
ログは「,」区切りで内容を分けているため、見難い場合はカンマ区切りで縦に並べ変えましょう。そうすると下記のようになります。メッセージの箇所を見るとどのアクティビティ(プログラムの命令)で何が起きたかが分かるようになっています。このエラーの場合「"exploああああrer.exe"で開いているウィンドウが見つかりません。アプリケーションが起動しているかどうか確認してください。」というエラーなので、「exploああああrer.exe」がなんらかの理由で見つけられなかったという事が分かります。
【エラーログの出力項目(標準)】
【メッセージ内容】
画面の状態とこのエラーメッセージだけではどこの処理でエラーが起きたか分からない場合は、エラー前のログを見ます。それでもたどり着けない場合はプログラム(XAML)を確認します。ログにXAML(プログラムのファイル拡張子)名も出力されるので、対象のXAML内でアクティビティ検索すれば辿り着けます。アクティビティ名称を重複させてはいけない理由の一つがこの障害対応時の調査がし難くなるためです。重複しているとどこのアクティビティでエラーになっているか特定が難しくなります。
また、このエラーログはUiPathの標準で出力されているものですが、Try Catchというアクティビティで囲った後に標準エラーメッセージを出力しないようにしていると標準エラーログが出力されない作りになり、非常に障害分析が難しくなります。現在そのような作りになっていて、エラー特定に支障をきたしているなら、出力するように修正を入れた方が良いです。
本来出力されるはずのログが途中から書かれていない場合は、UiPathのソフトウェア自体が内部処理異常で強制停止している場合があります。原因は内部異常(バグや.NETレベルで異常)が考えられ、この事象の時に初めに疑うのはメモリが足りなくなって異常終了したかです。このように「Execution.log」でエラー内容が分からない場合はWindowsのイベントログも確認する事で原因特定ができる場合があります。「ソース」列がUiPathでUiPathのログが出力されます。メモリエラーの場合は「Out of memory」という文言が出力されます。イベントビューアーは問題が特に起きていない時にもERRORとして出力している時があるので、問題なく動作している時には出力されていないものかを確認すると良いです。
「Out of memory」の他に現在は発生しないようですが、Excelアプリケーションスコープを多重で起動すると稀に内部エラーで異常終了するケースがあります。メモリエラーではない内部エラーはこのようなエラー可能性を疑い、ログが途切れている直後の処理を確認しましょう。
UiPath公式ドキュメントにログレベルやログフィールド(出力内容)について、説明されている所があるので、より詳細理解したい方はこちらも参照下さい。docs.uipath.com
原因分析
状態やログの内容を確認したら、なぜそうなってしまったかの原因を特定していきます。原因を特定する際のポイントとして下記があります。
<原因特定の観点>
①表面的な事象だけにとらわれない。根本原因や背後要因を視野に入れる
②事実を書き出して整理する
③事実から仮説を立て、対策から検証を繰り返す
④同じ問題の解決策情報がないか確認する
表面的な事象だけにとらわれない。根本原因や背後要因を視野に入れる
障害は複数の問題が絡んで発生するケースがあります。下記の例では問題事象が起きているのはパソコンで「セレクターが見つかりません」というエラーメッセージが出ていますが、原因はパソコンではなく、サーバー側で異常が起きていて、結果画面遷移が正常に行われず、「セレクターが見つかりません」となるケースもあります。パソコンで問題が起きているからといって、パソコンだけの視野でいると原因を特定する事ができません。これはパソコンとサーバだけの話ではなくパソコン内の起動しているアプリケーションでも同じことが言えます。初めから視野を狭くし過ぎてはいけません。後述で説明しますが視野は原因に関係ない事が確認できている所から狭めていくものです。
事実を書き出して整理する
これは非常に大事なポイントです。障害対応時に実際に確認している事と推測や予想が混ざってしまい、まだ実際に確認していない事を確認したと勘違いしたり、起きていない事を起きたと思い込んでしまったりします。このような事にならないように事実と推測は明確に分けて、書き出しておくと良いです。自分で解決できない場合に誰かに助けを求める際、事実ではない事を事実だったとして伝えると原因特定がかなり遅れる事があります。また、確証があまりない事を予想で伝えるのも混乱を招くことがあるため、思い付きで発言して障害対応現場を混乱させてしまう事は避けましょう。
事実から仮説を立てて対策から検証を繰り返す
実際に起きている事、確認した事、当時の状況から「こうなったから障害が起きたのではないか」と仮説を立てます。仮説の観点では冒頭で説明した「モノ・ヒト・コト」の視点で考えると良いです。午前8時にロボットが特定のファイルを上書きしようとした所、エラーが起きたケースで考えると、なぜエラーになったかの原因として、「モノ」はファイルがそもそも壊れていたという仮説になります。ファイルが壊れてなければ、「ヒト」によって、ファイルのフォーマットが削除や変更されていないかという仮説を立てます。「コト」は午前8時に誰かがファイルを掴みっぱなしにして保存できずエラーになったかのような仮説になります。
このように「モノ」「ヒト」「コト」が起因して障害を起きたのでないか仮説を立てて事実確認をしていきます。
上記の観点で確認しても原因が特定できなかった場合、更に切り分けを行い特定していきます。
<切り分けの観点>
①手動でやった場合はエラーになるか
②この事象は開発中に起きていたか(初めての事象か)
③再現率は100％のものか
④開発機と本番機が異なる場合、本番機だけで起こるものか(他では起きていないか)
⑤本番機でデバッグ実行した場合に発生するか
手動でやった場合はエラーになるか
RPAでやらずに人がやっても処理がエラーになり結果、障害になっている事があります。これを確認する事でRPA特有の問題なのかそうではないのかを切り分けます。
この事象は開発中に起きていたか
元々動いていたものが動かなくなった場合、処理対象に何かしらの違いが起きているか設定値やバージョン等の状態が変わっている可能性が高いため、新たなにポップアップが出るようになっていないか、セレクターが変更されていないかを確認します。
再現率は100％のものか
再現率が100％ではない場合は、処理遅延や正常終了する場合と異常終了する場合の違いはないか、関連システム側に問題はないか確認を行います。特定の文字が入力に含まれていると上手くいかないケースや特定の分岐処理の場合に上手くいかないケースがあります。また、まったく再現しないものに対して、確認するとたまたまネットワークがその時切れていたから発生していたものであったケースもあるため、再現性があるかどうかは確認して再現しない場合は二度と同じ異常が許されない場合を除き、事象再現待ちとした方が良いです。
他では起きていないか
特定の端末やログインユーザのみ発生するかしないかを確認する事により、環境の差分(各設定値等)で問題が起きていないかを切り分けられます。Excelのリボンの表示内容がAとBの端末で違っていてBは正常に動くけどAは動かない場合は設定を揃ってないのが原因というように特定できます。
本番機でデバッグ実行した場合に発生するか
デバック実行だとエラーが起きる時の操作対象の状態や変数にセットされている値まで確認できるため、原因の特定がし易いです。デバッグは上手くいくのに本番機での実行は上手くいかないケースは処理が空振りしているか、URの場合はOrchestratorが展開している画面サイズや解像度によって問題が起きているケースもあるため、人がリモートデスクトップで接続している状態とOrchestratorが実行している状態のエラー前後画面の比較のスクリーンショットを取り確認すると良いです。
同じ問題の解決策情報がないか確認する
「エラーメッセージ UiPath」でインターネット検索すると、過去誰かが対応を行い、その情報がインターネット上で公開されていれば、切り分けして問題特定までしている情報にたどり着ける時があります。見つからない場合はエラーメッセージだけで検索するのも有効です。他プログラム言語や製品でも類似の対処方法が見つかる事があります。
以上のように障害の原因はヒト(ファイルを消す、変更する)やモノ(設定値、ネットワーク、処理遅延、他システム障害、システム側のUI変更、バージョン)やコト(どんな状況で起きたか)で様々存在します。どこから確認していくかはエラー内容と状況によって怪しいと思われるところが変わってきます。この感覚の部分はわかり易く説明できるように整理できたら別途記事を書こうと思います。
自身やチーム内で原因に辿り着けない、早く対処が必要な場合はライセンスを有償契約しているのであれば、UiPathのカスタマーサポートに問い合わせする事で解決する事が多いです。私自身正解に辿り着けない場合はUiPathやMicrosoft(Windows)のカスタマーサポートに問い合わせをして専門家のアドバイスを貰います。
対処の実施
原因が特定できたら対策を行っていきます。下記に対処の例を記載していきます。本番で実際に動かしてみて解決したか確認が取れるまでは、「結果確認⇒再度調査⇒原因分析⇒対処⇒結果確認」を繰り返します。
【障害対処の例】
〇処理対象のUIが変更になっていた
⇒アクティビティを取得し直す
〇処理遅延で空振りしている様子だった
⇒Find Elementやセレクターのオプションの待機時間、準備完了まで待機を見直す
〇アプリケーションの設定が誤っていた
⇒正しい設定に揃える。正しい設定が何かを設計に残しておく
〇人がロボットを更新するファイルを掴んでいた
⇒ロボットの更新付近は触らないように運用を徹底させる。又は、該当のエラー時に閉じるように人に連絡して処理を一時停止するように作り込む
ワークフローが安定しないような障害の場合、安定化させるためのノウハウをUiPath公式が公開しているので、こちらを参照して対策を実施すると良いです。
クレスコという会社のこちらの技術ブログも人気です。
まとめ
原因の特定や対処の実施について、これまで少し詳細に説明をしてきましたが、障害対応ができる人が抑えている事は下記の通りです。長々と書いてしまいましたが「確認すべきログの場所と見方を知る」と「発生状況から判断」、「インターネットで検索」で解決可能な問題は多くあります。下記図のLevel1の部分をまずはできるようになりましょう。業務担当者の方は、エラーが起きた際に試しに自分で原因特定できるかチャレンジしたり、システム担当者の調査に協力可能な範囲で協力したりして頂ければと思います。
障害対応レベルを上げるために役に立つ情報
障害対応レベルをあげるために役に立つ記事や書籍を最後に紹介します。
コンピューターってどんなしくみ？：デジタルテクノロジーやインターネットの世界を超図解 (子供の科学★ミライサイエンス)
コンピュータの仕組みやコンピュータ同士が繋がる仕組みや簡単な歴史、コンピュータの何が危険なのかわかり易いように書かれている子供向けの書籍です。コンピュータやネットワークの仕組みが全然分からないという方にとてもお勧めです。メモリ？CPU?OS?という方でもついていけます。楽しみながらITの基礎知識を学べます。ここに記載されている事が理解できると、ITパスポートの参考書に書かれている内容も理解し易くなるため、ITリテラシー向上の入り口としてお勧めです。
ゼロから理解するITテクノロジー図鑑
これまで書いてきている単語がそもそも分からないものが多く、調べてもよく分からない人にお勧めの書籍です。IT基礎の単語の意味をイラスト付きでわかり易く説明されているので、ITに苦手意識がある人も理解し易いと思います。上記の子供向けの本を読んだ後だと、こちらも抵抗なく読み進める事ができると思います。
エラーメッセージの読み方と対処, 検索や質問の原則 Qiita
エラーメッセージ自体の読み方や検索や質問時の注意点が纏められている記事です。検索する際の文字をどこから選択すればいいか分からない場合や、質問しても何度も聞き換えられてしまっている人はこちらを参考にして頂く事でレベルを上げられると思います。
アメリカの中学生が学んでいる 14歳からのプログラミング
「コンピュータの仕組み⇒プログラム基礎⇒Scratch⇒Python⇒インターネットの仕組み⇒サイバーセキュリティ⇒Webページ構築」の順番でプログラミングに必要な知識をわかり易いイラスト付きで説明している書籍です。子供向けの書籍ですが、義務教育でプログラミングを学んでいない世代には、わかり易く必要な基礎知識の概要を身に付ける事ができるためお勧めの書籍です。ここに記載されている知識をわかり易い教材で理解するか、理解しないかは今後の学習や開発でのスキルの習得速度にも影響してきますので、この基礎はRPAやノーコード開発者も身に付けておく事をお勧めします。
公式ガイド UiPathワークフロー開発 実践入門
UiPath公式が出版している書籍です。UiPathの製品について全体的に抑えるべきポイントをわかり易く知る事ができます。公式のホワイトペーパーからサンプルをダウンロードできるため、サンプルを確認して良さそうであれば書籍を持っておくのが良いです。現場に1冊置いて皆で読むのも良さそうです。
OSの仕組みの絵本
WIndowsの仕組みやメモリ、ディスク、ネットワーク、CPU、プロセスについてわかり易いイラスト付きで絵本の様に学習できる書籍です。私は同じシリーズのJavaの絵本を購入し、わかり易いため他のシリーズもほとんど所持していますが、これと自分が理解したいプログラム言語の絵本さえあれば他は購入しなくても良いかなと思います。プログラム言語は似ている記載が多いため1冊あれば他は他書籍やインターネット情報で十分です。詳しくない人への説明が苦手なプロの方にもお勧めです。
Web技術の基本
ブラウザを使った自動化で問題が多く起きる場合にWebの仕組みを知っていると原因特定や対応の役に立ちます。この書籍は仕組みの概要が説明されており、お勧めです。記載レベルは基本情報技術者くらいのものです。
IPA:情報処理システム高信頼化教訓集 ITサービス編 別冊Ⅱ：障害分析手法
障害分析の手法の知識を身に着けたいという方にお勧めの情報です。
https://www.ipa.go.jp/files/000071988.pdf
トラブルシューティング(デバッグ)について実体験から学んだこと Qiita
デバッグのコツについて纏められている記事です。デバッグ慣れしていない方やデバッグが苦手な人は参考にすると良いです。
その他UiPathについての記事纏めリンク
UiPathの事について、色々と他にも記事を書いています。知っておくと良い情報を纏めていますので、参考にして貰えたらと思います。
