プロセス監視

「システムは止めてはならない」

どのようなシステムもそうですが、
証券システムはその最たるものです

トレーダーはその瞬間の売買、1秒1秒を勝負していますから
システムが止まって売買ができなければ損を被るわけです

システムの可用性を語る時に
プロセス障害時のフェイルオーバーの仕掛けが必要になってきます

Serviceguardのような製品でパッケージを組んでフェイルオーバーすることもあれば・・・

http://h50146.www5.hp.com/products/software/oe/hpux/component/ha/serviceguard.html

監視用シェルを用意して障害の検知及びフェイルオーバーを仕掛ける場合もあります

監視用シェルは監視対象のプロセスとは別サーバーに配置します

なぜなら、プロセスの障害のうちサーバー障害などのH/W障害が起因の場合
監視用シェルも同様にダウンしてしまうからです

監視用シェルの大まかな仕掛けとしてはこんな感じでしょうか

(1)pingでサーバー疎通確認
(2)remshでpsコマンド等を実施して監視対象のプロセスの起動を確認
 ⇒バックグラウンドでremshを実行する場合、
  監視シェル側でremshが完了したかを確認する
  一定時間remshが終わってなければ問題があるため障害とする
(3)(2)確認結果から障害か否かを判断
 ⇒障害であれば待機系フェイルオーバーさせる

製品の導入が一番確実ですが、
なかなか高価なものなのでどこにでも導入するというのは現実的ではないですね

ITに詳しい顧客

顧客企業のシステム部門のある程度の年次の人は
若手SEよりもITに詳しいことが多々あります

若手SEよりもシステムに長く携わっていれば
顧客の方がITに詳しくても仕方がない部分はあります

とはいえ、「顧客の方がITに詳しい」という事実を
「仕方がない」で受け入れることは中々難しいようで、
そういった顧客からの質問や疑問に
すぐに答えられなかった自分に引け目を感じて
ドッと疲れてしまう・・・

お恥ずかしながら私はよくあります

では、どうするのか

「ITに劣っている自分が顧客のために何ができるのか」
そこを考えて行動することです

顧客よりITのスキルが劣っているのが現状であり、
一朝一夕で差が埋まるようなものでもありません

それは仕方がない現実です

であるのであれば、
顧客の希望を汲み取り、
調べてでも聞いてでも全力でそれに応じることは
若手だろうができることです

立ち回った結果
時には間違った回答をしてしまうこともあります

ITに詳しい顧客に先に解決策をもらってしまうこともあります

間違った時には
謝れば良い
正しい回答を伝えれば良い

顧客に解決策をもらったら
お礼を言えば良い
今度は先に解決策を出せるように精進すれば良い

「顧客のために真摯に行動できているか」
そこが一番重要だと感じています

【VBA】UTF-8のBOM取り

職場ではソース管理とドキュメント管理に
Apache Subversionを利用しています

Apacheには主に認証とログ出力の役割を持たせています

認証自体は外部のドメインコントローラが行い、
認証後の権限はテキストファイル(svnaccessfile)で制御しています

svnaccessfileには権限を設定するリポジトリパスと、
そのパスに対してユーザーに与える権限を記述します

この時、Excelにてユーザー名やリポジトリ名・権限を記載し、
svnaccessfileを出力するようなマクロを利用しています

このsvnaccessfileは文字コードUTF-8でなければいけないため、
マクロによるテキスト出力はADODBオブジェクトを利用して行っています
(TextStreamオブジェクトではUTF-8は出力できません)

しかし、ただUTF-8にするだけでは正常に作動せず、
BOM(エンディアンを判別するための先頭3バイトのマーク)を削除する必要があります

実装はこのような感じで行いました

                          • -

Private target_txt As Object
Private result_txt As Object

'オブジェクト作成
Set target_txt = CreateObject("ADODB.Stream")
Set result_txt = CreateObject("ADODB.Stream")


〜〜〜〜省略〜〜〜〜

'''BOM削除'''

target_txt.Position = 0 'ファイルの先頭に戻る
target_txt.Type = 1 'テキストからバイナリへ変更
target_txt.Position = 3 'BOMのサイズ分位置をずらす
result_txt.Type = 1 'テキストからバイナリへ変更
result_txt.Open
result_txt.CopyTo result_txt '結果出力ファイルへBOMを抜いた部分をコピー

'ファイル保存
result_txt.SaveToFile "ファイル名" 2

                          • -

中々文字コードなりBOMなりで引っかかったので
備忘録的に載せてみました

CppUnitを使ってみた

開発で初めてCppUnitを使って単体テストを行いました

JUnitJava単体テスト自動化フレームワークですが、
CppUnitC++単体テスト自動化フレームワークです

私が実施したテストが一般的なものかはわかりませんが、
CppUnit実行に必要なものは主に以下のものです

CppUnit関数ライブラリ
②テスト結果出力用ソース
③テストソース
④テスト対象メソッドを含むモジュール

①、②は一度環境を設定してしまえば
プログラムの改修等ではあまり触れることは無いと思います

改修した(または追加した)ソースをコンパイルして生成されたモジュールを
所定の位置(CPPUNIT_ROOTなど環境変数にて指定)に配置し、
単体テスト仕様書に合わせてテストソースを修正します

テストソース内には
テスト実施前の初期化の内容であったり
テストケース毎に期待値を記述します

実際にやってみて感じたことは、
期待値はテストソースの中にベタ書き状態なので
ケース追加やケース修正を伴う度に手間がかかるということ
(テストソースを直す度に要コンパイル)

事実、テストソースの修正に大分手間を取られてしまいました

とはいえ、テストソースさえきっちり書ければ、
テスト実施・検証は効率的かつ正確に行えるので
有益なフレームワークではあると思います

自動化は効率化・正確化のために行うものですから、
期待値は外部ファイルから取り込むようにするなど
効率化・正確化をより強める工夫が必要ですね
(これは使う側の問題ですね)

実際の使い方はこちらのサイトが参考になりそうです

C++開発者のための単体テスト入門
第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
http://www.atmarkit.co.jp/fdotnet/cpptest/cpptest02/cpptest02_01.html

説明資料の贅肉たち

顧客への説明資料の作成は難しいですね
日々感じております

最近、過去の障害について説明資料を作成したのですが、
「ちょうど良い」レベルの資料を作るのが苦手です

ついついあれもこれもと作り込みすぎるのですが、
作り込まれすぎた資料はちょっとマニアックになってしまうので
説明資料の説明が多くなってしまいます
(本末転倒ですね)

詳細なロジックまで載せるのは過剰であるため、
下記のポイントのみに絞って資料を作成しました

  • 登場人物(サーバー名やプロセス名、DBのテーブル)は何か
  • 正常時の挙動はどうなのか
  • 障害時の挙動はどうだったのか
  • 何が問題だったのか
  • どうすれば解消できるのか
  • 時系列で動きを追えるか

挙動を説明するときにプログラムの中身が見えるようなロジックまで書くと
資料は途端に贅肉が増えてしまいます

贅肉のないような資料作り、心がけていきたいです

証券システムが求める確実性

証券会社のシステム開発では
アクロバティックなコーディングより
地味だけど確実なコーディングが好まれる傾向がある気がしますが、
他の証券システム開発SIerはどうなのでしょうか

金融や証券のようなお金をダイレクトに扱うクリティカルなシステムでは
「間違いのないように」が第一であるため、
多少コーディングがスマートでなくても確実性を求める必要があると考えています
(業務系のシステムはどこもそうかもしれませんが・・・)

利用するミドルウェアも最新のバージョンを使うのではなく、
枯れた実績のあるバージョンを利用する傾向が強いです

また、納期優先で開発したシステムなどは
後から見返すと「なぜこんなコーディングをしているのか」と思う部分が多々あります

しかし、カットオーバー後に安定稼働しているのであれば
たとえコーディングがイケてなくても
滅多なこと以外では直すことを嫌がります

ソースの見栄えが良くなることよりも
ソースに手を入れることのリスクを気にするからです

対して、Web系システムはアクロバティックなデザインを好む気がします
(やはりその分進化が早いと思います)

Webシステム系などは
障害が起こってユーザーが利用できなくなっても
「なんだよー」と文句を言われるだけで済むこともあるかもしれませんが、
証券システムはシステムを止めればそれこそ即損害賠償ものです


証券システムは何よりも「間違いのないように」なのです

教育IT EXPO行ってきました

東京ビッグサイトにて開催中の
第3回教育ITソリューションEXPOに行ってきました

※公式サイト
http://www.edix-expo.jp/

受付では招待券と一緒に名刺を2枚渡します
一枚は登録用、一枚は入館証に付ける用です

西ホール1、2という広い会場は
出展550社と大勢の入場者で賑わっていました

テレビカメラもちらほら見かけました
(今日の朝、NHKでも初日の映像が流れていましたね)

主にeラーニングや教育コンテンツのゾーンを見て回りました

やはりトレンドであるiPadなどのタブレット端末、
iPhoneなどのスマートフォンを用いた「どこでもeラーニング」の提案が多かったようでした

PCと比べて出来ることは遜色ない高機能デバイスを手軽に持ち歩くようになった昨今ですから、
これを利用しない手はないですね

気をつけなければならないのが、
この取り組みはeラーニングアプリを"作ること"ではまだまだ不十分で、
eラーニングを"続けられる""学習効果が上がる"となって初めて意味が生まれること

私も会社内の様々なeラーニングを受けましたが、
説明文が書かれたテキストが電子化された紙芝居程度のものであったので、
正直、しばらくしたら内容を忘れてしまいました

このeラーニングコンテンツの成功の鍵は
下記2点の留意点をおさえ、
「手放せない存在になれるかどうか」であると考えます

  • ユーザー目線になっているか

eラーニングは見栄えも良いですが、
それだけでは効果も出ないですし、
何より使い勝手が良くなければ続けて使ってもらえません

見栄えが良いからこそ、
提供側の自己満足になっていないか、
そこに気を付ける必要があります

  • モチベーション・動機付けができるか

以前から私が感じていたことですが、
企業研修向け、特に新人研修向けであれば
学習内容と実際の業務がどのようにリンクしているのかを見せる必要があります

また、学生向けであれば
"勉強を続けさせる"仕掛けが必要になります

今自分のやっていることが何になるのか、
何歳になっても知りたいものですし、
何歳になっても知ればモチベーションに繋がるものです

これらはeラーニングに限った話では無いですが、
eラーニングコンテンツも満たすべき必要条件だと思います

        • -

会場では気になっていた富士通ラーニングメディアさんの話も聞けました

業界大手の話は興味深いですね