アカウント名:
パスワード:
と、ここで説いても「それは会社の体質が」とか「管理者の説き伏せ方が」とかいうレスが戻ってくるんだろうなァ・・・(苦笑)
そんなことより、件のサーバがワームにやられた時、管理者自身(自分自身?)がその取引先会社から責任を問われる恐れはないんでしょうかね? 「何で対策しとかなかった」「なぜ危険性を説明しなかった」云々。わたしがその立場だったら、自己防衛のためにも、頑張ってアップデートの許可をもらうだろうなぁ... 仮にもらえなかったとしても、そのやり取りを全て文書で残しておけば、いわれのない管理不行届きで咎められなくてすむし。
1.サーバーの管理者(担当)は、やらなきゃいけない対策を上司(会社)に言う。 2.会社は、言ってる事が理解できない。理解できない事は重要なことではないと短絡的に思い込む。
上司を納得させるのは担当者の役目でしょ? あんたが説得しなくて誰が説得するのよ? それに気がついてないから「オタク」「マニア」扱いされるの、解ってる?
5.会社は、なぜ対策しなかったと身近なオタクに怒る。 6.担当は、対策しようとしたのをあんたが止めたと反論。 7.会社は、
ミッションクリティカルな場合、まずユーザーへのサービスを停止します。 #Apacheを止めるって意味じゃないですよ。「業」としてのサービスです。 その後初めて入れ替えが出来ます。 で、当然それだけではユーザーへのサービスを再開する事は出来ず、 運営責任者同伴で一通りの試験をして問題が無いと確認し、きちんと承認を 貰ってからで無いとユーザーのサービスは再開出来ないって事になりますから。
因みに、作業中は同伴している運営責任者から、 「1分止めるとウン十万円の損害なんだよねぇ。」 って御託が必ずと言って付いてくるのが何かと。
>また「テストマシンなんか無いよ」と言われる方に は、この際ですから >用意しましょう、と申し上げたいです。大体、本番サーバが壊れた時 >のバックアップ機があ れば、それをテスト用にも使える訳ですし。 >バックアップ機の定期チェックも出来て一石二鳥でしょう。 ちょっと甘いのでは?って気も。 ここ数年企業はどこもシブイですから。 某一部上場企業でもバックアップ機の購入契約を延期延期と引き伸ばすの が珍しく無いです。 また、今までの場合のバックアップやテスト機はどうだった?って言えば、 往々にして担当の私物だったり。が、どこも不況で収入が落ち込んでいる 現状では、それもままならない状況が続いている所も多いですし。
ちょっと異なるかな? テスト環境でのテストはやります。が、それによる結果確認は飽く迄 テスト環境のものであって、実機のものではありません。故に、実機での 再確認が必要となるのですが。
実際、微細な差によりトラブル発生ってのも無いとは言えないですし。 まあ、モノに依って(例えば、ページが見れなくて客がいらつく程度なら) は端折れる事もあるでしょうけど、1件の取引がウン十万ウン百万って なって来ると、 「ちょっとしたトラブルで消えちゃいました」 とは言えませんので。
つまり、どのレベル迄保証するのかの程度問題って事。 保証基準が甘ければ確認も簡単短時間で済むけども、保証基準がキツイと そうお手軽って訳にもいかない。 #尚且つ、運用試験手順書には、「運用試験は自動で行うだけでなく、 #必ず複数の人間が手入力して確認する」と書かれてたりするので、 #更に時間は嵩む訳で。
また、サービスを止める時は、必須1秒であっても、取引先の時計の誤差 なんかも考慮して安全マージンを取り、10分間とか告知するのも普通だと思います。
>バックアップ/予備機が用意出来ず、サービスを行なっている会社 >は、まあ存じております。
いや、上場企業のIT担当ですら、 「使わないバックアップ機はカネの無駄。」 と言いきる人もいます。 ましてや有象無象の企業ではサポート契約なしバックアップ無しってのも 珍しく無く、実際にソフトウェアアップデート無しって例も幾つもあります。 一応担当者にメールとFAXで通知は入れているんですが、結局 実害無しの為、放置されっぱなしってのも多いです。 まあ、相手も予算があっての行動ですし、こちらもボランティアとして 行う訳にもいかない(対処は出来てもその後に発生するトラブルの可能性 に対しての保証が契約していない個人では出来ない)です。 それなら、せめてアップデート手順を担当者教えてって思っても、 よっぽど責任感が強い人はともかく、大抵は新たな責任の発生を 嫌って「触れない」と言ってくるのが多いですし。 #まあ、外注に出すってのはそれらの保証と責任を買うわけだから #それ自体は理解出来ない訳で無いが。
故に、野良サーバは増えつづけるのでは無いかと。
実際にミッションクリティカルな業務であったとしても、それに使用する 予算を決めるのはそのその責任者であり会社ですから。 が、だからと言って運用を行わない訳には行かない。 となれば、永遠の暫定仕様のシステムってのが発生するのが往々にあります。 結果、ミッションクリティカルにも関わらず、それに即した構成に なってないシステムが多々存在るのが『現実』ってものです。 #って、元々理想論を外した問題の出る例を出していた筈ですので、 #「それはおかしいですね」って言われれば「そうですね」としか #言えないんですが。 もっと端的に、「ケチった結果」ってのも多いし。
>タレコミにある様に「脆弱なApacheサーバを放置している管理者」 >が最大の問題児 であるという意見には激しく同意してしまいます。
最大かどうかはさておき、問題であるのは確かでしょう。 が、それの基準が余りにも曖昧なレベルで他を責める書きこみが 多いのがちょっと。 パッチの適応が1時間であっても半日でも2・3日でも、危険を放置 している期間が存在するのは同じ。 確かに放置している期間が長い方が危険度は高いでしょう。 でも、それをOK・NGと別ける厳密な基準ってのは無いんですよ。 それを主観的な基準により「自分はOKそれより遅いとNG」的に 表現されていたりすると「なんだかなぁ」と思ってしまいます。 他人の目から見れば、その「俺的自分はOK」ってのでも遅すぎて 話にならないって可能性もありますし逆もありえますし。
実際、各サーバに人間を複数配してワッチをし、いざという時の為に バックアップ機材・要因を揃え、必ず人間が24時間監視しているって会社 ってどんだけあります? それによりセキュリティレベルが上がるのは確かですよ。 でも、ここで他人の怠慢を最大理由にしている人でもまずそこ迄は行って 無いのでは? でも、本当にセキュリティを重要視するプラントなんかでは常識 ですから、不可能でも非現実的でもないので、完璧を目指すのであれば やるべきではありませんか?
で、もしあなたがそこ迄やらないのであれば、その理由が即ち、他の仕事 にかまけてメンテを一日二日延ばしにする管理者の理由だと思いますが。 #やっているなら「凄いですねぇ」と素直に賞賛しますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
本業がマシン管理なひとならそれでもいいだろうが (スコア:2, 興味深い)
誰もが、サーバーの管理をして給料をもらっているわけではない。 サーバー管理より優先度が高い別の仕事をメインにやりながら サーバー管理もやらされている人は少なくない。
日がな一日セキュリティホールつぶし遊びをしていれば ソレで済む暇なオタクばかりじゃないんだよ、世の中は。
事情は色々ありますよ。 (スコア:2, 参考になる)
ただ、こちらの書き込みをされた方の文章も独善的ですね。
今回の問題はかなり広域なサーバーに影響を与えるにも関わらず、
修正まで公開を待てなかったISSに多少の問題があった様な気がします。
以前、自分もセキュリティ関係でとある会社のソフトウエアに報告をした事がありますが、
相手の反応を待って修正パッチが公開された頃に、警鐘の意味を込めて
「この様なセキュリティホールがある」と謳った事があります。
私の所属する会社でもApache 1.3.24(FreeBSD)が動いております。
これ、一刻も早くバージョンアップしたいのですが、
サーバー自体は取引先会社の物です。
サービス提供を行っている以上、勝手にサーバーを止める事はできません。
となると、取引先会社担当に承認を貰わなくてはいけませんが、
まず「そういった事に疎い」担当の場合、今回の重要性を理解してもらえません。
かかるかかからないかわからないワームより、目下のサービスが止まる事の方を
重要視します。
管理者から何度も問い掛けても難しい事って多々あるんです。
と、ここで説いても「それは会社の体質が」とか「管理者の説き伏せ方が」とかいうレスが
戻ってくるんだろうなァ・・・(苦笑)
ちなみに自分でできる範囲のサーバーはすべてアップデート済みです。
管理を行う以上、忙しいとか個人の怠慢で疎かにしてはいけないと思うので。
手前のサーバーが壊れるだけなら、そりゃ自業自得ってモンでしょうが、
ワームの場合、世界に迷惑をかけてしまいますからねぇ・・・。
Re:事情は色々ありますよ。 (スコア:1)
そんなことより、件のサーバがワームにやられた時、管理者自身(自分自身?)がその取引先会社から責任を問われる恐れはないんでしょうかね? 「何で対策しとかなかった」「なぜ危険性を説明しなかった」云々。わたしがその立場だったら、自己防衛のためにも、頑張ってアップデートの許可をもらうだろうなぁ... 仮にもらえなかったとしても、そのやり取りを全て文書で残しておけば、いわれのない管理不行届きで咎められなくてすむし。
それじゃいつものいってみよう。 (スコア:2, おもしろおかしい)
(とばっちりマニア鯖管理者VS団塊世代のほほん上司)
1.サーバーの管理者(担当)は、やらなきゃいけない対策を上司(会社)に言う。
2.会社は、言ってる事が理解できない。理解できない事は重要なことではないと短絡的に思い込む。
3.会社は、世間と同じものなら問題あるはずない。問題があれば世間も使ってるはずない。と思い込んでる。
4.だから、言ってきたやつがオタク(だからこんなヤツの言う事をまにうける事はない思ってる)場合は、やるなと反対する。そうして考えた意見を通した自分はエライつもりになる。
そうして問題が現実になると
5.会社は、なぜ対策しなかったと身近なオタクに怒る。
6.担当は、対策しようとしたのをあんたが止めたと反論。
7.会社は、(理解できなかった話で、覚えてもいないので)そんな話聞いていないと反論。
8.担当は、(証拠を残していれば)ここで説明したと反論。
9.会社は、(立場がまずくなると逆切れモードへ入り)こんな難しいこと理解できるか!やるべき事をやらない担当が悪いと怒る。(無知であれば自分に責任は無いと思ってる)
10.結局、会社への事前連絡は無駄といった結果に終わり、安定稼動は担当者の独断で全て運用するしかなくなる。
11.会社は、オタクが勝手に何かやってると思うようになる。
そして悪循環にはまる。
ちょっとオフトピだけど。
どうもオタクとマニアが同一視されてるけど、オタクって引きこもりの意で、マニアとは別物でしょ?
オタクがマニアの技術面をもつ場合もあるけど、マニア=オタクは成り立たないじゃないかな。
そして、世間は、「理解のできないマニア」=「オタク」と見てるね。
そもそもオタクって引きこもってるから特殊な場所でしか見ることないって事に気付いてない。
そして一度オタクと思ったら、何を言っても真に受ける事ないって意識が働き、やる気がなければ無視する。やる気があれば反対する。
また、問題を指摘した情報を見せても、セキュリティ系のNEWSやメールは、どんな所であってもオタクの戯言としか捕らえず、知っている大手新聞の言う事しか信用しない。
そんな彼らを動かすには、日経等に大きく記事にしてもらうしかないと結論つけたけど、どうでしょうか?
Re:それじゃいつものいってみよう。 (スコア:0)
上司を納得させるのは担当者の役目でしょ?
あんたが説得しなくて誰が説得するのよ?
それに気がついてないから「オタク」「マニア」扱いされるの、解ってる?
物証残してるとこうなる。 (スコア:1)
大丈夫です。言うだけじゃなく企画書や稟議書で出すのも含んでます。
彼らは内容を理解する気も実力も元々無いので、はじめは無視、追及すると無条件に否認してくれます。
また、否認に理由を求めてはいけません。求めると提灯記事で知ったろくでも無い物を並べ立てて、導入しろと指示します。
結果、たいした理由の説明が無いどころか、状況をより悪化させます。
そして、事件発生後、証拠を突きつけると9)に突入です。
この時、
理解できない、理解できるように説明しろとの一点張りで自分のバカさ加減を披露するモードと
理解できる説明を出来ないやつが悪いと怒って自分のバカさ加減を披露するモードの2種類があるます。
あと、証拠を突きつけても、見てないの一点張りで無知を押し通すのも居ますね。
どれも、担当者が何を言っても理解する気も実力も無いので、担当者自信の説明は全く無駄に終わります。
しかし、例外として彼らには大手マスコミの言う事は鵜呑みにするといった習性があります。
そこで担当者が自分の言葉ではなく、マスコミの記事をみせると内容を理解できなくても理解できたつもりになります。
ただし、マスコミが出した対策方法をそうっと採用する事。彼らに対策方法を出す機会を与えると、問題を理解してないので、悪化させるような事を真顔で言い出します。
以上により、担当者が仕事をするには、のほほんな上司の「信頼済みサイト」マスコミを見つけ出し、そこが必要な対策の記事を出す事を待つ・・・いや、事件が起こる前に積極的に対策を記事にしてもらうように働きかける事。記事が出たら直ぐに企画書を上げる。特に参考資料として記事の方が重要。
といった所で有意義な対策になるかな。
オタクでもマニアでもなく (スコア:0)
あんたが説得しなくて誰が説得するのよ?
それに気がついてないから「オタク」「マニア」扱いされるの、解っ
てる?
至極あたりまえだけど、
「オタク」でも「マニア」でもなく、「プロフェッショナル」として
仕事するなら、いかなることがあろうと自分の仕事には責任を持たな
ければならない。
もしとんでもなく石頭な上司に遭遇して、と
出来のいい人が絶滅の危機に瀕してない? (スコア:1)
> ホントに人の上に立つような人は、それなりに人間の出来がいいです。
ほんと、さらに上の上司の人間の出来がいい場合は、かなり幸せな環境です。
社長までにまともな人が居る場合は救われますが、最後まで続く場合は救われないです。
数年前はそれで助かりましたが、最近の状況として出来のいい人は、
・実力が高い。
・のほほんな連中に愛想をつかしやすい。
といった事もあり、辞めていく率が高く、気が付けばのほほんな連中が年功序列で占めてしまう状態って多いんじゃないでしょうか。
実際の話で、私が出した決済書を否認し、私が居なくなっても運用できる物と言って、導入する物を逆に指定された事ありますが、その後、私は他部署へ異動。後任は名前だけ。それにもかかわらず、問題が起ると後始末できる人が居ないので、他部署にもかかわらず対策をさせられる事が今でも続いてますよ。
結局、責任放棄しようがどうしようが見渡せる範囲内に居れば災いがふりかかります。
どうも、
・オタクの言ってる事は、何言ってるかわからない。(事前対策の考えなし)
・オタクに後始末をさせればなんとかする。(事前対策をとらないと対処できない場合を認識してない)
と勝手になんとでもなると思っています。
そして彼らの頭の中には、「自分にわからない事がわかってる(ように見える)若手社員」=「オタク」って認識があります。
この認識のきっかけは、ろくでもない事をやらかして、しかたなく対策してくれた身近な若手社員がこの位置付けにされてしまいます。
その後、ろくでも無い事を次々と引き起こし、それの対応と必要に迫られて勉強するしかなくなり、不幸な若手社員はマニアの領域まで達するも、認識は「オタク」。
逆に要領の良い人は、パソコンがわからない振りして「オタク」に見られないようにしている人も居ますね。
他にも
必要に迫られて勉強しているから対応できているにもかかわらず、オタクの技術を評価してない為、その認識は「引継ぎ」の一言で誰にも代りができると軽視している。
そして、引き継ぐ後任は、何もしらないドシロートを指名し、指名された本人は勉強する気もなし。言われた手順通りに操作するぐらいは出来るが、問題への対策に手順が前もってあるはずもなし。
結果としてだれも管理できてない物が多くなる。
まぁ、プロフェッショナルなら引継ぎをきちんとするべきなんでしょうが、プロからプロの場合だけ。
引き継ぐ相手がプロで無いケースが多々あります。
そんな原因を作り出す彼らの認識を改めないと、管理者不在の野良サーバーが増え、回りに迷惑をばらまくだけです。
せめて、出来のいい人が絶滅しない事を希望。
私の会社は、数人(他部署も含めても片手で足りる程度)生き残ってるけど、知り合いの会社、絶滅で苦労してますねぇ。
Re:事情は色々ありますよ。 (スコア:1)
FreeBSDではApacheを使ったことないのですが、Linuxの場合はApacheを動作させたままrpmでバイナリを入れ替えても、動作には影響ないんですけど?
なので、停止するのはApacheを再起動するための1-2秒間だけで済むはずなんですけどねぇ。
私だったら、サーバーの負荷が少ない時間帯にこっそりと入れ替えちゃいますね(笑)
#でもこういう客に限って、1時間くらい停止してても気が付かなかったりする。
Re:事情は色々ありますよ。 (スコア:1)
御意。ぼくの管理下にあるサーバはslackベースですが、apacheの入れ替えをする手順は、
(1) テストマシン(本番マシンと同様の構成)で新apacheのビルド&インストール
(2) テストマシンでの新apacheのチェック(ややこしいCGIとかがあるのでこれは必須)
(3) 新apacheのバイナリをパック。及びpkgを作成(お客さんへの配布用)
(4) 本番マシンに仮のディレクトリで新apacheを展開
(5) 旧apacheの停止、旧apacheディレクトリの名前を保存名に変更、新apacheのディレクトリを本来の名前に変更、新apacheの起動、を(1コマンドラインorスクリプトで)一気に行う
となります。HTTPサービスの停止時間は、まあ、数秒でしょうね。apacheをアップデートするのに、旧apacheを停止してから延々とビルド等を行う必要は更々無い訳です。また「テストマシンなんか無いよ」と言われる方には、この際ですから用意しましょう、と申し上げたいです。大体、本番サーバが壊れた時のバックアップ機があれば、それをテスト用にも使える訳ですし。バックアップ機の定期チェックも出来て一石二鳥でしょう。
Re:事情は色々ありますよ。 (スコア:1)
FreeBSD の話になりますが,独立したマシンの代わりに Jail を用意するのも今後の定番になりそうですから指摘しておきます.
シビアな管理者であれば,本番のサーバもなんらかの Sand Box での実行を考慮すべきですね.
Re:事情は色々ありますよ。 (スコア:1)
>するのも今後の定番になりそうですから指摘しておきます.
jailは、満足なテストが出来ない場合があり、必ずしもテストマシンの代わりにはならない場合もあるでしょう。
>シビアな管理者であれば,本番のサーバもなんらかの Sand Box での
>実行を考慮すべきですね.
確かに人様が作られた(サーバ)ソフトウェアで、プログラム的な欠陥から特権的なオペレーションが可能になってしまうものに関しては、jailは有効です。ですが、それよりは最初から特権的なオペレーションが不可能なソフトウェアの構成の方がより良い構成では無いでしょうか。ぼくはその様にソフトウェアを作成しています。
まあ、とは言え、その様なソフトウェアでもプログラミングをしくる可能性は0では無いですし、設定をミスる場合もあるでしょうから、jailの中で動かす事はベルトと吊りバンド併用的な、考慮すべき方法論の1つですね。設定や構成がより複雑になりかねないと言うデメリットも勘案して、無用の事であるない、採用するしないは、実装者and/or運用者の判断でしょう。
Re:事情は色々ありますよ。 (スコア:1)
ミッションクリティカルな場合、まずユーザーへのサービスを停止します。
#Apacheを止めるって意味じゃないですよ。「業」としてのサービスです。
その後初めて入れ替えが出来ます。
で、当然それだけではユーザーへのサービスを再開する事は出来ず、
運営責任者同伴で一通りの試験をして問題が無いと確認し、きちんと承認を
貰ってからで無いとユーザーのサービスは再開出来ないって事になりますから。
因みに、作業中は同伴している運営責任者から、
「1分止めるとウン十万円の損害なんだよねぇ。」
って御託が必ずと言って付いてくるのが何かと。
>また「テストマシンなんか無いよ」と言われる方に は、この際ですから
>用意しましょう、と申し上げたいです。大体、本番サーバが壊れた時
>のバックアップ機があ れば、それをテスト用にも使える訳ですし。
>バックアップ機の定期チェックも出来て一石二鳥でしょう。
ちょっと甘いのでは?って気も。
ここ数年企業はどこもシブイですから。
某一部上場企業でもバックアップ機の購入契約を延期延期と引き伸ばすの
が珍しく無いです。
また、今までの場合のバックアップやテスト機はどうだった?って言えば、
往々にして担当の私物だったり。が、どこも不況で収入が落ち込んでいる
現状では、それもままならない状況が続いている所も多いですし。
Re:事情は色々ありますよ。 (スコア:1)
ミッションクリティカルなシステム、ぼくが絡んだものは、テスト環境(本番データを使用、外部へのサービス提供は無し)で検証を行って、が手順でしたが。勿論、ソフトウェア移行の後に本番サーバで最終試験はしますが、それは移行後の確認ですね。世間一般の業として行われているミッションクリティカルな用途では、テストとは現物合わせ、つまりサービスを提供を止めないとテストは出来ない、と言う、いわば情けないマネジメントで行われているのが普通なのでしょうか?是非この点についてご教授をお願いしたいです。
バックアップ/予備機が用意出来ず、サービスを行なっている会社は、まあ存じております。悪徳というか、ハコモノ重視のSIに乗せられて、えらく高いマシン(パフォーマンスもC/Pも決して良くはありません)を買ってしまい、予備機を買う金が無くなってしまった、とかで。人事を尽くさず天佑神助に期待、しかし残念ながら神様はそう甘い顔ばかりもしてくれず、メンテが入るまでの3日間はサーバが止まりっぱなし、の様な格好良い姿を世間に晒す訳です。こういうマネジメントは論外とは思いますが、現実にその様な事が行われているのもまた事実。その様なマネジメントが通用するとすれば、ソフトウェアのアップデートとかも無しと言うか無視となるのでは、と考えてしまいます。実際、セキュリティホールの博物館と化してたりします(笑)。
Re:事情は色々ありますよ。 (スコア:1)
>では、テストとは現物合わせ、つまりサー ビスを提供を止めないと
>テストは出来ない、と言う、いわば情けないマネジメントで行われ
>ているのが普通なのでしょうか?
ちょっと異なるかな?
テスト環境でのテストはやります。が、それによる結果確認は飽く迄
テスト環境のものであって、実機のものではありません。故に、実機での
再確認が必要となるのですが。
実際、微細な差によりトラブル発生ってのも無いとは言えないですし。
まあ、モノに依って(例えば、ページが見れなくて客がいらつく程度なら)
は端折れる事もあるでしょうけど、1件の取引がウン十万ウン百万って
なって来ると、
「ちょっとしたトラブルで消えちゃいました」
とは言えませんので。
つまり、どのレベル迄保証するのかの程度問題って事。
保証基準が甘ければ確認も簡単短時間で済むけども、保証基準がキツイと
そうお手軽って訳にもいかない。
#尚且つ、運用試験手順書には、「運用試験は自動で行うだけでなく、
#必ず複数の人間が手入力して確認する」と書かれてたりするので、
#更に時間は嵩む訳で。
また、サービスを止める時は、必須1秒であっても、取引先の時計の誤差
なんかも考慮して安全マージンを取り、10分間とか告知するのも普通だと思います。
>バックアップ/予備機が用意出来ず、サービスを行なっている会社
>は、まあ存じております。
いや、上場企業のIT担当ですら、
「使わないバックアップ機はカネの無駄。」
と言いきる人もいます。
ましてや有象無象の企業ではサポート契約なしバックアップ無しってのも
珍しく無く、実際にソフトウェアアップデート無しって例も幾つもあります。
一応担当者にメールとFAXで通知は入れているんですが、結局
実害無しの為、放置されっぱなしってのも多いです。
まあ、相手も予算があっての行動ですし、こちらもボランティアとして
行う訳にもいかない(対処は出来てもその後に発生するトラブルの可能性
に対しての保証が契約していない個人では出来ない)です。
それなら、せめてアップデート手順を担当者教えてって思っても、
よっぽど責任感が強い人はともかく、大抵は新たな責任の発生を
嫌って「触れない」と言ってくるのが多いですし。
#まあ、外注に出すってのはそれらの保証と責任を買うわけだから
#それ自体は理解出来ない訳で無いが。
故に、野良サーバは増えつづけるのでは無いかと。
Re:事情は色々ありますよ。 (スコア:0)
Re:事情は色々ありますよ。 (スコア:1)
実際の所、ミッションクリティカルなシステムはその様なタイトな運用が行われているものにしかコミットしていません。(日本の)世間一般にはどの様な方針で運用が行われているのか分からなかったため、ご教授を願いました。そこまでのタイトな要求は(多分日本で、だと思いますが)ミッションクリティカルなシステムの運用に求められていない、がお答えの様ですね。勉強になりました。
「使わないバックアップ機はカネの無駄」と言い切るIT担当者、ありがちですね。敷衍すれば「セキュリティホール潰しなんざ金の無駄」となる訳で。振り返ってapacheの事に話を戻すと、タレコミにある様に「脆弱なApacheサーバを放置している管理者」が最大の問題児であるという意見には激しく同意してしまいます。それが独善的である、出来ない事を強要してる、等の意見は、将に現状のpoorなマネジメントを是認している事で、「ぼく、悪くないもん!」的なオコチャマ発想と考えたりします。
Re:事情は色々ありますよ。 (スコア:1)
実際にミッションクリティカルな業務であったとしても、それに使用する
予算を決めるのはそのその責任者であり会社ですから。
が、だからと言って運用を行わない訳には行かない。
となれば、永遠の暫定仕様のシステムってのが発生するのが往々にあります。
結果、ミッションクリティカルにも関わらず、それに即した構成に
なってないシステムが多々存在るのが『現実』ってものです。
#って、元々理想論を外した問題の出る例を出していた筈ですので、
#「それはおかしいですね」って言われれば「そうですね」としか
#言えないんですが。
もっと端的に、「ケチった結果」ってのも多いし。
>タレコミにある様に「脆弱なApacheサーバを放置している管理者」
>が最大の問題児 であるという意見には激しく同意してしまいます。
最大かどうかはさておき、問題であるのは確かでしょう。
が、それの基準が余りにも曖昧なレベルで他を責める書きこみが
多いのがちょっと。
パッチの適応が1時間であっても半日でも2・3日でも、危険を放置
している期間が存在するのは同じ。
確かに放置している期間が長い方が危険度は高いでしょう。
でも、それをOK・NGと別ける厳密な基準ってのは無いんですよ。
それを主観的な基準により「自分はOKそれより遅いとNG」的に
表現されていたりすると「なんだかなぁ」と思ってしまいます。
他人の目から見れば、その「俺的自分はOK」ってのでも遅すぎて
話にならないって可能性もありますし逆もありえますし。
実際、各サーバに人間を複数配してワッチをし、いざという時の為に
バックアップ機材・要因を揃え、必ず人間が24時間監視しているって会社
ってどんだけあります?
それによりセキュリティレベルが上がるのは確かですよ。
でも、ここで他人の怠慢を最大理由にしている人でもまずそこ迄は行って
無いのでは?
でも、本当にセキュリティを重要視するプラントなんかでは常識
ですから、不可能でも非現実的でもないので、完璧を目指すのであれば
やるべきではありませんか?
で、もしあなたがそこ迄やらないのであれば、その理由が即ち、他の仕事
にかまけてメンテを一日二日延ばしにする管理者の理由だと思いますが。
#やっているなら「凄いですねぇ」と素直に賞賛しますよ。
Re:事情は色々ありますよ。 (スコア:1)
ちなみに、1秒でも2秒でも「停止」は「停止」です。
結構厳しいんですよ、対社外の契約は。自分のせいでは無くても信用問題に関わります。
それに自分の所では常にサーバを監視していますので、止まったという記録はlogに
残ってしまいます。
そして、万が一デーモンが起動してこなかったら?
担当の勝手でその様な事態を引き起こしてしまったら、会社にどれだけの損害を与えるかわかりません。
サーバ管理者である以上、常にリスクマネージメントを行う必要があります。
勝手に入れ替えができ、万が一止まっても全然平気なモノなら良いのですが・・・
結局、別契約で使用していたロードバランサを一時的に利用しました。
同じ構成のテストマシンを併用し、コネクションを見ながら0になったらアップデート。
というカタチにしました。
停止時間は限りなく0に近い状態でアップデートできました。
ま、一番苦労したのは上と契約先担当の説得でしたけど(苦笑
Re:事情は色々ありますよ。 (スコア:0)
結局、サラリーマンは現実に悩み、学生は好き勝手言ってる
だけじゃん。アノカワでもいいが、先頭に学生かサラリーマン
かくらいは明記して欲しいな。ちなみに俺はサラリーマンだ。
Re:事情は色々ありますよ。 (スコア:0)
> だけじゃん。アノカワでもいいが、先頭に学生かサラリーマ
> かくらいは明記して欲しいな。ちなみに俺はサラリーマンだ。
給料もらっているんだから,いばらないように。ちなみに,俺は
どっちでもない。