OSI参照モデルとは、ノード（コンピュータ）間の通信を定めた規格のことで、通信に必要な要素を７つの層に分けて規定しています。
この規格により、異なるベンダの機器を使用していたとしても通信が行えるようになっています。
OSI参照モデルについて、応用情報処理技術者試験で出てくるレベルの知識はないと、ネットワークエンジニアと会話することができません。
その意味で、アプリケーションエンジニアであったとしても、必要な知識になります。
今回、OSI参照モデルの規定内容・主なプロトコル・主な通信装置を一つの表にまとめましたので、公開します。
この表で知識を整理するだけでも、応用情報処理技術者試験の問題は概ね解けるはずです。
いかがでしたでしょうか。
今回は、自分の頭を整理するために作っていた一覧表を公開しました。
このような一覧表は時々作成するので、これからも公開していきたいと思います！
システムの運用においてトラブルの対策を考える際、インパクトが大きいトラブルに対しては大きな労力を、そうではないトラブルに対しては小さな労力をかけるのが効率的です。
ここで、ホビーの売買サイトの運用を例に挙げて説明します。
例えば、エンドユーザーが直接触る画面において、金額計算を間違えてしまった場合、直接クレームに繋がってしまいます。
このようなインパクトの大きいトラブルの発生が想定される場合、予め念入りにテストしたり、本番リリース後にもテストを行ったりして、トラブル発生を防ぐために大きな労力をかける必要があります。
その結果として、実際にそのようなトラブルが起こる可能性は小さくなります。
逆に、管理者しか触らない画面において誤字がある、という程度のトラブルであれば、謝罪して修正してリリースすることで、大事にならずにトラブルを解消することができます。
このような軽微なトラブルについては前述のような念入りなテストを行ったり体制を用意する必要性は薄く、他のトラブルの対策に労力を割いた方が効率的になります。
しかし、トラブルのインパクトの大きさを過小評価してしまった場合、本来かけるべき労力をかけずに、高確率で大きなトラブルが発生してしまいます。
例えば、１日の売上記録を他システムへファイル連携するバッチ処理を想定します。
当該の他システムが開発中であり、その他システムではただファイルを受信しているだけであれば、ファイルの中身が誤っていたとしても後で時間をかけて検証して修正すれば、大きなトラブルになることはありません。
このトラブルで済むのであれば、開発者が作成したデータでテストで済ませ、リリース後も後で時間をかけて結果を検証する、という程度の労力でも通常は問題ありません。
しかし、開発中でファイル未取り込みだと思っていた当該の他システムが、実はファイル取り込みも行っている、しかも管理者がシステムテストのために処理結果を見ている、となった場合、システムテストのスケジュールに影響を与えてしまうというトラブルになってしまいます。
更に、取り込んだデータの修正も必要になるため、リカバリーにも時間がかかるという厄介なトラブルになってしまいます。
このレベルのトラブルになってしまうのであれば、本番データを想定したテストを事前に行い、リリース時も事前にファイルを出力し、出力結果に問題がある場合はファイル送信を差し止める、といった対応が必要になります。
前述のような少ない労力の対策では、本番で厄介なトラブルが発生する確率が高くなってしまいます。
このように、トラブルのインパクトの大きさを過小評価してしまうと、大きなトラブルに発展してしまう可能性が高まります。
それを防ぐために、トラブルのインパクトの大きさは予め有識者に確認しておく、確認できない場合は大きなトラブルが発生することを想定して労力をかける、ということが必要になります。
いかがでしたでしょうか。
今回は実務で発生したことを元にして、得られた教訓を記事として残しました。
実務から得られる教訓は貴重なものですので、これからも文章として残していきたいと思います。
コンティンジェンシープランとは、想定外の事態が起きた時に備えて事前に定めておく対応策のことです。
この記事では、プログラムのリリース時に定めておくべきコンティンジェンシープランについて、具体的に述べていきます。
プログラムのリリース作業は、事前に定められた一定の時間内に、プログラムを入れ替えて稼働確認を行う、という作業です。
例えば、特定の日の22:00-24:00をメンテナンス時間として事前に通知し、メンテナンス時間中はシステムの開放を止めてプログラム入れ替えと稼働確認を行う、というような作業を指します。
リリース作業時における主な想定外の事態は、稼働確認での不具合の発見です。
不具合を発見した時に備えて、以下のようなコンティンジェンシープランを事前に用意しておくべきです。
新しくリリースしたプログラムに不具合が存在していたとしても、リリース時間内に元のプログラムに戻して稼働可能な状態に戻せば、利用者にはリリース前と変わらない機能を提供することができます。
リリースによるサービス水準の低下を防ぐという意味では、最も確実な対応策となります。
ただし、切り戻し作業自体にリスクが存在する（切り戻し作業を失敗し、戻せなかったり、より自体が悪化したりする可能性がある）ため、切り戻し作業を行う可能性があるのであれば、作業手順を事前に確立させる必要があります。
データの移行を伴う場合は、データの事前のバックアップとその戻しも必要になるので、特に注意が必要です。
切り戻し作業を行うのが最も確実ではあるのですが、発見された不具合が軽微なものであれば、その不具合を許容した上で戻さずにリリース作業を完了させる手もあります。
また、法律改正への対応のような、外部の変更に応じた対応の場合は切り戻し作業の実施自体が難しくなる（自社の判断だけでは切り戻し作業ができなくなる）ため、この場合も不具合を許容、最悪の場合は機能制限を加えた上でリリース作業完了させる必要が出てくることが多いです。
不具合を許容するかどうかの判断はその時々で柔軟に判断する必要がありますが、それを誰が判断するのか（作業時の責任者は誰なのか）は事前に決めておくべきです。
また、機能制限のような作業を行う可能性があるのであれば、その作業手順も事前に確認・確立させる必要があります。
稼働確認で不具合が発見されたとしても、リリース時間内に修正できるのであれば、修正するに越したことはありません。
また、切り戻しを行うのかサービス水準の低下を許容するのかの判断が必要になる可能性もあります。
このように、不具合が発見されたとしても、切り戻しの行わない、という判断をすることがあります。
しかし、切り戻し作業にも時間が必要なので、その判断をいつまでに行うのか、ということは事前に決める必要があります。
例えば、24:00までにサービスを再開する必要があり、切り戻し作業に（余裕を見て）30分かかる場合、切り戻しを行うかどうかの判断は23:30までに行う必要があります。
23:30までに修正が完了しなかったり、サービス水準低下の許容の判断ができなかったりするのであれば、安全側に倒すために23:30を迎えた瞬間に切り戻し作業を開始するべきです。
いかがでしたでしょうか。
今回は、後輩に指導したことを記事として残しました。
記事に書いたことは、保守作業に携わるエンジニアであれば意識するべきことです。
大規模なシステムでは書類の形でプランを作る必要がありますし、小規模なシステムであっても関係者間で事前に認識を共有しておくべきです。
指導した内容はこれからも記事として残すようにしていこうと思います！
ゲーム理論については、前回の記事と前々回の記事で解説しました。
ゲーム理論は話だけ聞くと簡単そうに見えますが、実際に適用しようとするとある壁にぶつかります。
その壁とは、「適用対象をゲームとして正しく認識することが困難」という壁です。
ゲームとしての認識が誤っていると、ゲーム木や利得表を正しく書くこともできなくなり、そこから導き出される分析結果も誤ったものになってしまいます。
今回の記事では、この問題について例を挙げて説明し、どのような落とし穴があるのかを詳しく書いていきます。
ゲーム理論で分析を行うためには、以下の３つの前提条件が必要になります。
「適用対象をゲームとして正しく認識する」を具体的に言うと、「以下の３つの前提条件を正しく設定する」ということになります。
ゲーム理論とは、自分が選んだ選択肢と相手が選んだ選択肢の組み合わせで結果がどのように分岐するのかを分析する理論である。
そのため、まずは結果に影響を与えるような利害関係のあるプレイヤーを洗い出す必要がある。
前述の通り、ゲーム理論とは選択肢を選んだ結果を分析する理論であるため、その「選択肢」を洗い出す必要もある。
ゲーム理論における「結果」は「利得」と呼ばれているが、その利得の大小も定義する必要もある。
上記の前提条件は、ゲーム理論の例題では自明です。
しかし、現実世界の問題では前提条件は自分で設定する必要があります。
（スポーツ・ボードゲーム・コンピューターゲーム等のような実際に遊ばれているゲームに対してゲーム理論で厳密に分析する場合にも、前提条件を疑う必要があります）
これらの前提条件を設定するのは意外と難しいです。
以下では、ゲーム理論の代表的な例題である囚人のジレンマでの例を挙げて説明します。
一見利害関係がありそうなプレイヤーは実は利害関係がなかったり、逆に意外なプレイヤーと利害関係があったりします。
囚人のジレンマの例では、相手の囚人の行動が自分の量刑に影響しないのであれば、相手の囚人をプレイヤーとして仮定するのは不適です。
また、被害者の気分で量刑が変わるのであれば、被害者をプレイヤーとして見立てるべきです。
発想を膨らませると、選択肢も色々なものが想定できます。
囚人のジレンマの例では「黙秘」「自白」のみが選択肢として与えられていますが、囚人の能力や状況次第では「賄賂支払」「脱走」といった選択肢も想定する必要があります。
各プレイヤーの目的や価値観、心理的バイアス、外部から与えられた要素等によって、実際に感じる利得は変化します。
例えば、囚人のジレンマにおいては、プレイヤーには「刑を免れる」以外の目的はないことが前提として置かれています。
しかし、現実世界では「正義の主張」という目的が潜んでいる可能性があります。
この場合、自白をすることで「正義の主張」という目的を果たすことができ、それがプレイヤーの主観的な利得に影響を与え、そのプレイヤーにとっては自白一択になる可能性があります。
ここまでで述べたように、ゲーム理論の前提条件の設定には難しさがあります。
ゲーム理論を現実世界で用いるためには、現在のゲームがどのようなゲームなのか、メタ的な目線で分析することが欠かせません。
囚人の量刑を決める場面で常に囚人のジレンマが発生するとは限りません。
先入観に捉われず、現在の状況をゲームに置き換えるとどうなるのか、というのをその場その場で考える必要があります。
その上で、ゲームを作り変える、という視点があるとより有効にゲーム理論を活用することができます。
例えば、囚人のジレンマの例で言うと、予め財を成しておけば、「賄賂支払」という選択肢が選択肢が生まれ、相手の選択肢に関わらず無実を勝ち取れるゲームを作り出すことができます。
どのようにゲームを作り変えれば良いのか、を考える上でも、ゲーム理論の現状分析は役に立つと思います。
いかがでしたでしょうか。
長くなりましたが、ゲーム理論に関する一連の記事は以上になります。
ゲーム理論は情報処理技術者試験のような試験で勉強する内容ですが、せっかくであれば試験対策だけでなく実際に活かした方が良いと思っています。
今回の記事では、実際に活かすにあたって注意するべきことを挙げてみました。
これからも、実践に即した記事を書いていきたいと思います！
ゲーム理論については前回の記事で触れましたが、今回の記事はその続きです。
今回の記事では、混合戦略の確率の求め方について、詳細を書いていきます。
混合戦略は、何度も同じゲームを繰り返す場合において、相手がどのような確率で選択肢を選んだとしても、全ゲームで得られる平均の利得を一定にすることを意図したものです。
長期的な目で見て、利得が下がるリスクを最も軽減できる戦略です。
この戦略の実現方法について直感的に書くと、リスクの高い選択肢（相手が選ぶ選択肢によって利得が大きく変わる選択肢）を選ぶ確率を少なめに、リスクの低い選択肢（相手が選ぶ選択肢によって利得が大きく変わるらない選択肢）を選ぶ確率を多めにすると、混合戦略に近くなります。
各選択肢の選択確率を正確に求めるには、連立方程式や微分方程式等を用いて計算を行う必要があります。
今回の記事では以下の前提で計算を行います。
選択肢Ａを選ぶ確率をp、選択肢Ｂを選ぶ確率を1-pとおく。
混合戦略が成り立つ時、相手が選択肢ａを選んだ場合の期待利得と相手が選択肢ｂを選んだ場合の期待利得は等しくなるため、以下の式が成り立つ。
|
1 2 3 4 5 6 7 8 |
選択肢ａを選択…2*p + 5*(1-p) …① 選択肢ｂを選択…6*p + 4*(1-p) …② ①＝②のため 2*p + 5*(1-p) = 6*p + 4*(1-p) 2p + 5 - 5p = 6p + 4 - 4p -3p + 5 = 2p + 4 -5p = -1 p = 0.2 |
以上より、選択肢Ａを選ぶ確率が0.2、選択肢Ｂを選ぶ確率が1-0.2(=0.8)の時に、混合戦略となる。
選択肢ａが選ばれる確率pが決まる時、選択肢ｂが選ばれる確率は1-pという形で一意に求まる。
また、混合戦略の定義は、「相手が選択肢ａを選んだ場合の期待利得と相手が選択肢ｂを選んだ場合の期待利得が等しくなるように選択肢を選ぶ」である。
そのため、混合戦略の定義は、「相手が選択肢ａを1の確率で選ぶ場合の期待利得と相手が選択肢ａを1-1(=0)の確率で選んだ場合の期待利得が等しくなるように選択肢を選ぶ」と置き換えることができる。
そこで、相手が選択肢ａを選ぶ確率をx軸、自分の利得をy軸に置くと、以下のグラフを得られる。
下記のグラフについて、線分Ａ-Ａ’は選択肢Ａを選んだ場合の利得、線分Ｂ-Ｂ’は選択肢Ｂを選んだ場合の利得、線分Ｃ-Ｃ’は混合戦略となる場合の利得を示している。
線分Ａ-Ａ’と線分Ｂ-Ｂ’を式に表すと以下のようになる。
|
1 2 |
線分Ａ-Ａ'の式…4x + 2 線分Ｂ-Ｂ'の式…-x + 5 |
線分Ａ-Ａ’と線分Ｂ-Ｂ’を微分し傾きを求めると、以下のようになる。
|
1 2 |
線分Ａ-Ａ'の傾き…4 線分Ｂ-Ｂ'の傾き…-1 |
ここで、線分Ｃ-Ｃ’は混合戦略であり、xの値によらずyは一定のため、傾きは0である。
線分Ａ-Ａ’をpの比率で、線分Ｂ-Ｂ’を1-pの比率で合成し、線分Ｃ-Ｃ’を生成する場合、比率pは以下の式で求まる。
|
1 2 3 4 |
4*p + -1*(1-p) = 0 5p - 1 = 0 5p = 1 p = 0.2 |
以上より、選択肢Ａを選ぶ確率が0.2、選択肢Ｂを選ぶ確率が1-0.2(=0.8)の時に、混合戦略となる。
選択肢Ａを選ぶ確率が0.2、選択肢Ｂを選ぶ確率が0.8の時の期待利得を求める。
相手が選択肢ａを選んだ場合、自分の期待利得は以下のようになる。
|
1 |
2 * 0.2 + 5 * 0.8 = 0.44 …① |
相手が選択肢ｂを選んだ場合、自分の期待利得は以下のようになる。
|
1 |
6 * 0.2 + 4 * 0.8 = 0.44 …② |
①と②が等しいため、選択肢Ａを選ぶ確率が0.2、選択肢Ｂを選ぶ確率が0.8の時に混合戦略となる。
教育機関で教えられるのは連立方程式を解く方法で、複雑な状況に対応することを考えるとこちらの方法を用いるべきです。
しかし、プレイヤーが二人で選択肢が二択というような簡単な状況では、微分方程式を解く方法の方が簡単にイメージできます。
傾きを合成して0にするだけなので、簡単に書いてしまうと「選択肢Ａの傾き:選択肢Ｂの傾き*-1」の逆数がそのまま「選択肢Ａを選ぶ確率」と「選択肢Ｂを選ぶ確率」になります。
上記の例で言うと、「4:1」の逆数「1/4:1」=「1:4」=「0.2:0.8」が「選択肢Ａを選ぶ確率」と「選択肢Ｂを選ぶ確率」になります。
手続き型のプログラムで計算できるように計算式を書くと、以下のようになります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
選択肢Ａの傾き = (選択肢Ａ・選択肢ｂの時の利得 - 選択肢Ａ・選択肢ａの時の利得) 選択肢Ｂの傾き*-1 = (選択肢Ｂ・選択肢ｂの時の利得 - 選択肢Ｂ・選択肢ａの時の利得)*-1 選択肢Ａの選択確率 = 選択肢Ｂの傾き*-1 / (選択肢Ａの傾き + 選択肢Ｂの傾き*-1) 選択肢Ｂの選択確率 = 選択肢Ａの傾き / (選択肢Ａの傾き + 選択肢Ｂの傾き*-1) ※以下の場合は劣等戦略が未除外のため、エラーとする。 ・選択肢Ａ・選択肢ａの時の利得 ＞ 選択肢Ｂ・選択肢ａの時の利得 かつ 選択肢Ａ・選択肢ｂの時の利得 ＞ 選択肢Ｂ・選択肢ｂの時の利得 ・選択肢Ａ・選択肢ａの時の利得 ＜ 選択肢Ｂ・選択肢ａの時の利得 かつ 選択肢Ａ・選択肢ｂの時の利得 ＜ 選択肢Ｂ・選択肢ｂの時の利得 ※以下の場合は選択肢Ａの選択確率・選択肢Ｂの選択確率を共に0.5とする。 ・選択肢Ａ・選択肢ａの時の利得 = 選択肢Ｂ・選択肢ａの時の利得 かつ 選択肢Ａ・選択肢ｂの時の利得 = 選択肢Ｂ・選択肢ｂの時の利得 |
いかがでしたでしょうか。
今回の記事では、前回の記事では簡単にしか触れなかった混合戦略について、詳しく書いていきました。
実際にゲーム理論を応用する場合は、数字や確率で状況を表すことが難しい場合が多いので、「リスクの高い選択肢を選ぶ確率を少なめに、リスクの低い選択肢を選ぶ確率を多めにする」という直感的な理解で問題無いと思います。
ゲーム理論を現実世界に応用する際には、いくつかの注意点があります。
それを、今後の記事で書いていきたいと思います。
