ラベル 安定稼働 の投稿を表示しています。 すべての投稿を表示
ラベル 安定稼働 の投稿を表示しています。 すべての投稿を表示

2021年6月26日土曜日

寿命30年の自社開発システム!

(システムの費用対効果〈 システムの寿命 〉を改題)

30年動いてきたオフコンがありました!すごいですね。開発の費用対効果もさることながら、バージョンアップやデータ移行などの無駄もなくシステムの鑑です。パッケージ、ERPの方が楽だというのは本当でしょうか?大企業でなければERPのバージョンアップコストとても払えません。

30年前の設計書も残っていました。手書きで感動しますね。設計書を見ると、30年の間にシステムの使われ方が変わってきたことがわかります。現在は販売管理業務がメインなので使用帳票とヒアリングから、業務フロー、データ定義、画面プロトタイプも起こしました。ただ30年前のデータ仕様書は参考にしました。業務システムの根幹はデータ設計です。今回のシステムはマスタ以外のデータ移行はないので、テーブル構造、データ定義の制約はないので、データ設計をさらにシンプルにしましたが、イレギュラーケースの想定など念のためデータ仕様書を確認しました。

リレーショナルデータベース(MariaDBです)のビューやトリガのおかけで性能を維持しプログラム数も減らすことができました。フロントエンドがアクセスなのでクエリにデータフローを記述できるので手書きのプロシージャも最小限です。その分、便利機能を盛り込むことができました。

過去、私の関わった比較的大規模なシステムで、アパレル全社基幹システム、医薬品卸営業支援システム(SFA)、配送トラック動態管理サービス* があるのですが、どれもシステム稼働から10年を越えて安定稼働を続けている・続けた* ものです。ハードウェア交換は行っていますが開発されたプログラムは動き続けています。どれもスクラッチ開発です。

一方、パッケージ導入は稼働延長したものでも8年が限界でした。意外なのですが、パッケージの方が寿命が短いです。古い環境に特別対応できないからですかね?メジャーバージョンアップにぶつかって、実質的に再導入というケースもありました。もう別の製品ですね。

パッケージといっても大体アドオンするのでそんなに安くないし、アドオンプログラムのバージョンアップ対応でお金が出ていきます。製品保守費の15-20%が毎年自動的にかかっているのに、さらに上乗せされるお金です。会社の中で、金食い虫と情報システム部が白い目で見られる訳です。でも自社システムを開発する要員もいないし、中途半端にベンダーに頼らざるを得ないのが現状ですね。問題は業務別のシステム、パッケージという名のブラックボックスの乱立で、今度は運用管理やデータ連携に苦労することです。そこまでは外部に頼れず、結局、運用管理にシステム部の人手がとられてしまう。悪循環です。

パッケージソフトって、それ一つだけだとメリットが感じられるのですが、複数の組み合わせとか、連携とかになると途端に出来ないことが出てきて運用しづらくなります。
ユーザサイドも苦労して導入したソフト、せっかくなので長く使い続けたいですね。費用対効果のメリットも出てきますから。運用まで考えてパッケージ選定、システム設計したいです。

パッケージ導入、コツがあります。システムフローの尾っぽ部分はセーフです。頭部分は要注意、胴体部分は・・・
SAP 困っていませんか? 国産ソフト、クラウドベースやオープンソースですっきりさせるのも一案です。
永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

追記 2020年1月6日
ワークフローソフトをパッケージ導入頂いたお客様を久しぶりにご訪問させて頂きました。無事、運用されているとのこと。安心いたしました。
お客様が大変協力的で(システムは賢くはないことをご理解いただき)アドオンなしで導入頂いております。末永くご利用いただきたいと思います。

2020年6月1日月曜日

マルチホーミング

マルチホーミング、わかります?ITの世界でマルチホーミングといえば物理的なネットワークの冗長化です。最近とんと聞かなくなりましたが、可用性確保で案外落とし穴かもしれません。クラウド流行りでエンジニアも希少化しているのではないでしょうか。インフラ担当としてアサインされたら焦りますよね。。


クラウドへのアクセスはアプリケーションプロバイダーの責任範囲から外れるのまずネットワークの冗長化要件が来ることはないのですが、以前は自前でマシンを設置してアクセス回線を手配していたので、冗長化も仕事の範囲でした。

最初に確認することは、NTT以外の幹線が建屋の近くの(道路の下)に来ているかで、来ていれば建屋への引き込みを依頼します。大技で有線回線と無線回線を併用するなんてのもありました。冗長化の趣旨からするとできるだけ異なる特性のものを組み合わせたほうが良いので悪くないアイデアです。

さて難しいのは、なじみの薄いL1,L2レイヤーを意識しないといけない点ですが、現在はフルIPなのでまだましですね。それでもルーターを用意してBGPの設定となると、なかなか手ごわいですね。できればパスしたいです。できるのでしょうか?
ことと場合によると出来ます。負荷分散としても割りと悪くない方式だと思います。概略を紹介します。

フロントウェッブは一般的なクラウドサービスに配置し、アプリケーションサービスを別のサービスサイトから提供することとします。マルチホーミングの対象はサービスサイトのみです。
ネームサーバーに www.***.com (フロント), svc1.***.com (サービス1), svc2.***.com (サービス2)の3ホストを登録します。フロントはサービス1、サービス2をタイムアウト付きでコールする javascript を組み込んだページを返します。
もうお分かりですね。サービス1が障害されていれば、タイムアウトしてサービス2にアクセスするという簡単なものです。サービス1のホストが回線A経由で、サービス2のホストが回線B経由でアクセスされます。2つのホストが同一DC内であれば疑似マルチホームで、別々のDCであればDC可用性確保になります。
* サービス1、サービス2のIPアドレスがクラスター共有されていれば元々の定義のマルチホーミングらしくなりますが、やるかどうかはユーザーメリット次第ですね。

何も難しいことはありませんし安上がりですぐに適用できますね。というか、DC可用性確保は基本しておいた方がいいです。有名なクラウドサービスもダウン前提ですから(フロントも複数のホストに配置し、ネームサーバーに登録ですよ)。
タイトルと書きだしを否定するようですが、ルーターでマルチホーミングなんて割りが合いません。ajax のおかげで手軽にサービスレベルを上げることができます。
システム設計は、ユースケース、アーキテクチュア、インフラトータルで見ましょう。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)