自己満足は次のことにつながります：リスクが現実になる

私はOTNコミュニティの最近のスレッドに参加していました。そこでは、データベースのアップグレード後のダウングレードについて誰かが質問していました。回答の1つは、実際にデータベースのダウングレードを実践している人の数を尋ねました。調べるためにこの投票を作成しました。

そのスレッドへの1つの貢献を見つけて驚いた：

そのポスターはそれを明確に述べていませんでしたが、あたかもその個人がダウングレードの練習は必要がないので時間の無駄だと言っているかのようでした。私はポスターに疑いの利益を与えます、そしてこのオラクルの従業員は実際にこれを言っていませんでした。私はこの個人を選ぶつもりはありません。このスレッドで、より一般的な観点からトピックについて話し合う機会を提供します。（更新：このブログエントリを書くように促した投稿者は、私がこれを書くのにかかった時間にスレッドに戻ってきて、「ダウングレードを「テスト」するべきではないことを意味するものではありませんでした。」）

7月に、私はTheDataGuardianに関するブログ投稿を書きました。そのブログ投稿で、私は次のように述べました：

DBAはデータを保護する必要があります。それが仕事＃1です。ジョブ＃2は、DBAがデータへの効率的かつタイムリーなアクセスを提供することです。データにアクセスする必要のある人がデータにアクセスできない場合、データを持っていることはどのようなメリットがありますか？それらの人々がデータを操作するときにひどいパフォーマンスをしている場合、彼らはアクセスできない可能性があります。

DBAとして、リスク管理を行う必要があります。どのようなリスクが現実になるかを判断する必要があります。 DBAの仕事は、これらのリスクを測定し、2つの行動計画を決定することです。そのリスクが現実になるのを避けるためにどのような手順を踏むことができ、そのリスクが現実になったときに問題を解決するためにどのような手順を踏む必要がありますか？

ジュニアレベルのDBAでさえ、バックアップの重要性を理解します。バックアップはリスク管理戦略です。データが失われた場合、バックアップからデータを回復できます。また、ジュニアレベルのDBAでさえ、バックアップから復元できることの重要性を理解しています。

このOTNスレッドで、私はこれを書きました：

私にとって、これはマーフィーの法則のようなものです。私は過去に同じようなことを言いました。アイデア（およびこのブログエントリの要点）は、適切なリスク管理手順を実行しない場合、そのリスクを現実化するように神に求めているだけです。バックミラーの調整を拒否して、車両をバックアップするときに使用する場合は、その日が何かに戻ります。靴ひもを結ぶことを拒否した場合、それは私が靴ひもを踏んで旅行する日です。パワーツールを使用するとき、私が保護グーグルを着用することを拒否する日は、私が何かを目にする日です。私がビーチに行って日焼け止めを塗ることを拒否する日は、日焼けで家に帰る日です。アイデアが浮かびます。

一部の読者は、私が夢中になっていると思っているかもしれません。私が満足しているという理由だけで、宇宙にはこのマスタープランがありません。そして、私は同意します。つまり、別の言い方をすれば、リスクを軽減する予定がない場合、それが現実になるのを阻止するために何もしていません。私の怠慢のせいで、それが現実になる可能性は減りません。

リスク管理には2つの主要な要素があります。 1）そのリスク項目が発生する確率を決定し、2）そのリスクが発生した場合の影響を決定します。確率が最も高いアイテム発生する可能性が最初に軽減されます。これは簡単で、リスク管理に取り組んでいる多くの人がよく行うことです。彼らはリスク項目をスプレッドシートに入れ、そのリスクが発生する確率の値を入力します。完了すると、確率の列でソートし、リスクの軽減を上から下に開始します。多くのリスク管理戦略は、リストの中央のどこかに線を引き、その線より下のリスク項目は、そのリスク項目について心配しない可能性が低すぎると判断します。宇宙で起こりうるすべてのリスクを軽減することはできません。すべてを処理するのに十分な時間がありません。したがって、どこかに線を引く必要があります。

私がいつも目にする失敗の1つは、リスク管理が影響に焦点を当てるのに多くの時間を費やしていないことです。そのリスクの現実になります。スプレッドシートには、そのリスク項目のビジネスへの影響の評価を提供する同様の列を含める必要があります。リスクマネージャーは、この列のスプレッドシートも並べ替える必要があります。大きな影響を与えるアイテムは、発生する可能性が低い場合でも、リスク軽減活動を行う必要があります。悲しいことに、リスク管理ビジネスの多くは、リスクの影響を評価するこのステップを含めることができません。繰り返しになりますが、スプレッドシートをビジネスへの影響で並べ替えると、どこかに線が引かれます。

確率が高いリスクアイテムが見つかる場合があります影響が少ない、または非常に低いビジネスに。「確率x影響」という3番目の列を含むリスク管理スプレッドシートが好きです。この列は、2つのリスク要素間の関係を理解するのに役立ちます。

このブログ投稿を促したデータベースアップグレードの質問に戻りましょう。このブログ記事を読む人は誰でも、Oracleデータベースのアップグレードは危険な提案であることに同意する必要があると思います。 Oracleデータベースのアップグレードで問題が発生する可能性のあるさまざまなことがあります。確率アップグレードの失敗の割合はHIGHです。リスク軽減の項目には、多くの場合、本番環境のクローンでアップグレードを実行し、アップグレードプロセスを開始する前にデータベースをバックアップすることが含まれますが、これらに限定されません。なぜこれを行うのですか？さて、影響ビジネスへの非常に高いです。本番データベースのアップグレードに失敗すると、ビジネスユーザーはデータにアクセスできなくなります。この失敗を乗り越えることができなければ、私たちはあまり優れたデータガーディアンではありません。非本番環境でアップグレードを十分に実践すれば、リスク項目の可能性を中程度に減らすことができます。しかし、おそらく、その特定のリスク確率をLOWに下げることはできません。そのため、アップグレードを開始する前にバックアップを取ります。レベルを上げてもまだ問題があるはずです-確率を減らすのが最善ですそのリスク項目の影響ビジネスへのはまだ非常に高いです。したがって、DBAのリスク修復戦略は、アップグレードが失敗した場所と原因をメモし、バックアップから復元することです。データベースは稼働しており、影響を排除しました。ビジネスに。次に、DBAは設計図に戻って、問題を解決する方法を決定します。 DBAは確率を削減しようとしています後でアップグレードプロセスを再度実行するために戻ったときに、その問題が再び発生します。

それでは、OTNスレッドのコメントに戻りましょう。ここでは、データベースのダウングレードを実践することは時間の価値がないと言っているようです。同意しません。そして、私の意見の相違は、影響と関係があります。ビジネスに。ポスターが返信で言ったコメントに同意します。

私はその100％に同意します。なぜこの「徹底的なテスト」を行うのですか？それはすべてリスク軽減のためです。確率を削減しようとしていますアップグレードすると、パフォーマンスが低下したり、アプリケーションの機能が損なわれたりする可能性があります。しかし、そのポスターが言ったように、「アプリケーションの100％をテストすることは不可能であるため、アップグレード後に本番環境でポップアップする問題が常に発生します。」繰り返しになりますが、私はこのポスターがここで言っていることに100％同意します。しかし、影響についてはどうでしょうか。ビジネスに？これについてはすぐに説明しますが、最初にこの次の段落で少し逸脱する必要があります…

最近、重要な本番システムを11.2.0.4から12.1.0.2バージョンにアップグレードしました。私が働いている場所では、他の仕事でこれまでに見たよりも多くのアプリケーションテストがあります。テストを行う完全なQAチームがあります。自動テストの取り組みを担当するチームもあります。アプリケーションコードを毎晩実行する自動ロボットがあります。その上、コードの変更をTestまたはProdにプッシュするたびに、このルーチンが重要なコードパスをすばやく調べる別の自動化されたルーチンがあります。開発環境（15以上）を12.1.0.2にアップグレードし、1か月待ちました。次に、テストをアップグレードし、3週間待ってから本番環境をアップグレードしました。本番環境をアップグレードする前に、問題が見つかり解決されました。しかし、それでも、生産がアップグレードされると、大きな問題が発生しました。 10月中旬から12月中旬に私のブログ投稿にアクセスして、これらの問題のいくつかを確認できます。私はこのデータベースのダウングレードに非常に近かったのですが、代わりに問題を解決することができました。今、私が作っていたポイントに戻ります…

アップグレードが完了すると、データベースが営業用に開かれます。アプリケーションユーザーは、アプリケーションを使用できるようになりました。この時点でデータベース内で何が起こりますか？トランザクション！そして、トランザクションはデータの変更を意味します。アップグレードが完了した後、DBAがビジネス用のデータベースを開いた時点で、データの変更が発生し始めます。結局のところ、これがデータベースの要点ですよね。データの変更をキャプチャし、アプリケーションのエンドユーザーがデータを利用できるようにします。

では、データベースのアップグレードで去年の秋にボートに乗った場合はどうなりますか？すべてのテストを行った後でも、非本番環境では見られなかったものにぶつかっていました。影響ビジネスへの高さでした。このビジネスへの影響を減らすことができる必要があります。私には3つの選択肢がありました。 1）問題を1つずつ修正します。 2）データベースを古いバージョンに戻すことができるように、アップグレード前に作成したバックアップから復元します。 3）データベースをダウングレードし、製図板に戻ります。私は最初のオプションを選びました。私は私のキャリアの間にいつも持っているように。しかし、それだけでは不十分だった場合はどうでしょうか。問題の解決には時間がかかる場合があります。一部の企業は、そのようなマイナスの影響でそのような時間を費やす余裕がないだけです。ビジネスに。パフォーマンスがひどい、または物事が正しく機能しなかったために放棄されたWebサイトはいくつありますか？そして、そこにある本番データベースの大多数にとって、オプション2は非常にひどい影響を持っていますビジネスに！アップグレードが完了すると、トランザクションが失われます。 DBAは、データベースを古いバージョンのままにして、アップグレードをロールフォワードすることができないため、データが失われ、多くの本番データベースでは、これは受け入れられません。ビジネスは1時間のデータ損失を許容できるかもしれませんが、アップグレードから1時間以内にこのアクションのトリガーを引く人は何人いますか？おそらく、このアクションはアップグレードと影響の数日後に実行されます。その種のデータ損失のビジネスにとっては、非常に高いものをはるかに上回っています。そのため、オプション3は影響が最も小さいオプションとして残ります。アップグレード後にビジネスが経験している影響を解決するために、ビジネスに貢献します。

その最後の段落から、アップグレードの完了後にOracleDBAがデータベースをダウングレードする方法を知ることが重要であると私は感じていることがわかるでしょう。確率を認めますダウングレードを実行する必要があるDBAの割合は非常に低くなっています。しかし、影響ダウングレードしないことは、ビジネスに壊滅的な影響を与える可能性があります。（これらの2つの単語が再びあります）。確率低いので、ダウングレードはあまり練習しませんが、影響ダウングレードできないことの割合は非常に高いので、たまに練習します。

最後に、マーフィーの法則に戻ります。宇宙は私に対して陰謀を企てていませんが、データガーディアンとして、私は優れたリスク管理の原則を実践する必要があります。それは、私の変更によって課せられるリスク項目の確率と影響を評価することを意味します。宇宙と神々はマーフィーの法則やそのいとこたちを動かさないかもしれませんが、私はリスク項目を軽減することによって自分自身に恩恵を与えるつもりはありません。確率を1ビット下げていません。