アカウント名:
パスワード:
エスカレなしに24/365でシステムを稼働させるには・設計者の一部を夜勤にする・設計者の一部をポリネシア支店に転勤させる・ドキュメント化されてない障害が発生したらあきらめて翌営業日対応とする・約款にベストエフォートの文字をちりばめる・運用もオフショアさあどれになる？
なんで死ぬほど冗長化しないの？24/365が必須ならそれに見合ったシステムにしろよ。
いや、いくら冗長化しても夜間バッチこけたら、対応しないといけないでしょ。業務システムのバッチ処理がこける原因って、データ要素が大きいから、監視するだけの運用者じゃ対応できんもの。それに契約の関係で重要情報の閲覧権限もってないこともあるし。世の中、そんな簡単じゃないのよね。
冗長化できてないからでしょ？ハードウエア的なことしか頭にないのかな？
データ起因のソフトウェア停止って、冗長化関係ないじゃん。腐ったデータを食べて、エラーログだけ出して、後続を実行てワケにはいかないシステムもあるのよ、世の中には。
腐ってるデータは冗長化しても食べられないのに変わりはないと思いますが…周辺含めて破損データを送らないようになってるならいいでしょうけど世の中、完璧で一体設計されたシステムばかりじゃないんですよ
サブシステムごとにベンダーも設計も別の人だし導入年度もバラバラそういうものです
ようするに、最初から24/365のシステム作る気なんかないってことかそれならそうと最初から言ってくれよ。 ＃そもそも腐ってるデータが存在するのはバグだろ ＃あと、腐ってたら食わずに飛ばせよ
#2581459のコメントにもあるように、サブシステムごとに導入年度や利用者、ベンダが違うから、I/Fの仕様齟齬でありえないデータを突っ込まれて、バッチがずっこけるなんて、ままあることですよ。
別に24/365が要件のシステムの話してるわけじゃなくて、24/365じゃないシステムだって、夜間の繰越処理とかがあれば、こけたら、翌オンラインに影響があるから、夜間に対応するの当たり前でしょ。
ありえそうなパターンでひとつ。
たとえば、債権債務管理と支払管理が別々のサブになっていて、銀行の支店統廃合があって、口座マスタのメンテナンスをした場合、
・債権債務側の仕様がインタフェース時に有効な口座情報・支払側は支払日において有効な口座情報
ってな感じだと、インタフェース時には口座が有効だけど、支払時には支店がなくなって口座マスタが取れない、なんてことが起こりえます。
で、支払なんで、夜間バッチでエラーではじいておしまい、なんてことをすると、支払できないなんてことが発生し、信用問題ですよね。なので、こういう場合には、夜間に開発者にエスカレして対応するんですよ。
実際には、データの状態を確認して、いったん支払を起こしておいて、翌朝、一番に顧客（ユーザ）に確認をして、データにパッチを当てるなんてことになるんですけど。
最初からずっと「24/365のためにする」話してんのに、いまさら「別に24/365が要件のシステムの話してるわけじゃない」とかずれたこと言われても…
＃そんなにイケてないの認めるのが嫌かｗ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
システム運用という稼業 (スコア:1)
エスカレなしに24/365でシステムを稼働させるには
・設計者の一部を夜勤にする
・設計者の一部をポリネシア支店に転勤させる
・ドキュメント化されてない障害が発生したらあきらめて翌営業日対応とする
・約款にベストエフォートの文字をちりばめる
・運用もオフショア
さあどれになる？
Re: (スコア:0)
なんで死ぬほど冗長化しないの？
24/365が必須ならそれに見合ったシステムにしろよ。
Re: (スコア:3)
いや、いくら冗長化しても夜間バッチこけたら、対応しないといけないでしょ。
業務システムのバッチ処理がこける原因って、データ要素が大きいから、監視するだけの運用者じゃ対応できんもの。
それに契約の関係で重要情報の閲覧権限もってないこともあるし。
世の中、そんな簡単じゃないのよね。
Re: (スコア:0)
冗長化できてないからでしょ？
ハードウエア的なことしか頭にないのかな？
Re:システム運用という稼業 (スコア:2)
データ起因のソフトウェア停止って、冗長化関係ないじゃん。
腐ったデータを食べて、エラーログだけ出して、後続を実行てワケにはいかないシステムもあるのよ、世の中には。
Re: (スコア:0)
こういうヤツがチェックサムなしで電文送って1ビット欠けたら全データがおじゃんになるような素人設計するんだろうな
Re: (スコア:0)
腐ってるデータは冗長化しても食べられないのに変わりはないと思いますが…
周辺含めて破損データを送らないようになってるならいいでしょうけど
世の中、完璧で一体設計されたシステムばかりじゃないんですよ
サブシステムごとにベンダーも設計も別の人だし導入年度もバラバラ
そういうものです
Re: (スコア:0)
ようするに、最初から24/365のシステム作る気なんかないってことか
それならそうと最初から言ってくれよ。
＃そもそも腐ってるデータが存在するのはバグだろ
＃あと、腐ってたら食わずに飛ばせよ
Re:システム運用という稼業 (スコア:2)
#2581459のコメントにもあるように、
サブシステムごとに導入年度や利用者、ベンダが違うから、
I/Fの仕様齟齬でありえないデータを突っ込まれて、バッチがずっこけるなんて、
ままあることですよ。
別に24/365が要件のシステムの話してるわけじゃなくて、
24/365じゃないシステムだって、夜間の繰越処理とかがあれば、こけたら、
翌オンラインに影響があるから、夜間に対応するの当たり前でしょ。
Re:システム運用という稼業 (スコア:2)
ありえそうなパターンでひとつ。
たとえば、債権債務管理と支払管理が別々のサブになっていて、
銀行の支店統廃合があって、口座マスタのメンテナンスをした場合、
・債権債務側の仕様がインタフェース時に有効な口座情報
・支払側は支払日において有効な口座情報
ってな感じだと、インタフェース時には口座が有効だけど、
支払時には支店がなくなって口座マスタが取れない、なんてことが起こりえます。
で、支払なんで、夜間バッチでエラーではじいておしまい、なんてことをすると、
支払できないなんてことが発生し、信用問題ですよね。
なので、こういう場合には、夜間に開発者にエスカレして対応するんですよ。
実際には、データの状態を確認して、いったん支払を起こしておいて、
翌朝、一番に顧客（ユーザ）に確認をして、データにパッチを当てるなんてことになるんですけど。
Re: (スコア:0)
最初からずっと「24/365のためにする」話してんのに、
いまさら「別に24/365が要件のシステムの話してるわけじゃない」とかずれたこと言われても…
＃そんなにイケてないの認めるのが嫌かｗ