アカウント名:
パスワード:
>UNIXはサーバ再起動しなくても復旧できる方法は必ずある!
いや、具体的にその方法を示しているところがないだけだ。某BMも某UNも某Pも、さらに某立/某通/某ECさんも「待てば究明してくれて、確実に対処方法だしてくれるんですね?出せなかったら会社潰してくれますね?」と聞くと逃げる。優秀なエンジニアさんだと、さそれがきっと出来るのだろう。しかし、優秀なエンジニアさんは、今のところいない様にも思える。どなたかご紹介いただけますか?...www
>客にそこまで迫られたらワークアラウンドを見つける方に舵切りますけどねぇ。
実は客もそこらへんは知っているので、「サービスを無駄に止める可能性が高いダンプや自称エンジニアによる調査」は説得力を失っていたりする。ある意味、調べるために!とか言っている方々がほしがっているものをわざわざ与えたとしても、ほしがっている方々の技術では無意味だということなのでしょう。
>そんな浅い調査しか出来ないところから買うのをやめたほうがいい。
そうでしたら、SUN/CTC/HP/IBM各社さんから買うのをやめていらっしゃるのでしょうね。あ、そうそう、RedHatさんもだな。
>ワークアラウンドなんかある程度状況がつかめてないと出せない場合が多いし(運用を変えるならともかく)。
もちろん、ダンプやらログやら提出、最悪、エンジニア派遣していただいての調査とかね。しかし、それでフリーズの原因が究明されるまでそのままとか、無理でしょうなぁ。よほど、止まってもよいサーバのお仕事だけされていらっしゃるのでしょうね、うらやましいな。
>契約外なら「無理」の一言で返すだけなのに。外れ会社だよそれ。
実際、営業さんなんか、「我が社で調査して解明します」とかおっしゃるわけで、それが出来るといいね。
>そもそも、調査はわからないからするもので、結果がでることがわかってるなら誰も調査しません。
で、実績としてダンプを時間をかけて取るというのが無駄だということ。解析できる確率が低すぎる上に、停止時間への影響が大きい。SLAなどでは障害からフェイルオーバに何分と示してあるのに、情報収集だけでそれを上回る時間を必要としちゃう。SLAに調査のための時間を加味せずに締結しておいて、後から「調査のための時間」を別枠だとか思っている馬鹿がいるってのが問題。
約束通りにちゃんとやれ、出来ない約束をしたら、出来るまで糾弾する、面倒なんで潰れてくれない?というのもあるわけな。
>結局こちらのシステム部門の設定ミスでした、なんてこともありましたし。
それはそれで原因究明できたわけで、めでたいのでは?それが出来るのは、結構なことだと思います。
>そこら辺をしっかり説明できないのは、ベンダに「技術」がないからだと言えばそのとおりですが。
解明しますと言っておきながら、解明できない。解析します、で、ぜんぜん役にたたない。「弊社の技術にて解析」は、御社の無能を示すものでしかありませんな..といったところです。
解析成功確率を示して、それだけ低ければいらね..と最初からあきらめがつけさせてもらえると、ありがたい。所詮は、無能なのですから、無能だと最初から言って無能には荷が重いというか無理な契約はしてほしくないんですよね。無能相手にちゃんとしたアウトプットを出す様に指示するための会議とか、ほんと無駄なことになる。あの無能連中(自称エンジニア)のために、優秀だとは言わないが普通レベル程度の方々の時間を無駄にしたくないんだ。
> 「ダンプとってください」「ダンプとっても判らない場合、引責してもらえますね?」に、「はい、首を賭けて解明します」という回答を貰ったことがない。や、> 「出せなかったら会社潰してくれますね?」なんて事を思いつく人自らがやるべきですね。
>こういう発言の時点でトラブル解析の知識の無い人なのは明白
明白なのは、実績からするとトラブル解析に無意味な情報収集でサービス停止時間を無駄に増やそうとする馬鹿を排除しているだけですよ。
いやそんなアホなことを言うレベルの金をまず積んでるのか興味があるきっとそこの会社を買い取り出来るレベルの金を今まで払ってきたのだろう
だいたい首きってOKなんて言う客はまずいないそんな責任の取り方されても全く問題の解消にはならないからねまぁ、そんな気楽な事を要求出来る分下っ端なんだろうなぁとは思うけどw上の方の人はそんな事してもらっても何にも美味しくないしそんな要求することもないでしょうなw
>いやそんなアホなことを言うレベルの金をまず積んでるのか興味がある
いえいえ、全責任を持ちます、SLAでサービスダウンを1時間以内を目標とします..があるからね。いくら金を積んでいるか?ではなくて、契約とかSLAの問題。というか、SLAを守れない様な技術で開発に応じた側の問題でしかないわけです。
>そんな気楽な事を要求出来る分下っ端なんだろうなぁとは思うけどw
運用維持のマネージャさんとかも同じでしたね。そして、顧客もね。開発とベンダーが反論したけど、実績が糞すぎて相手にしてもらえないだけのこと。当然、無能でも発言権はあったりするので、そいつらの実績で詰んでしまうだけのことです。
そういったクズ相手している閑もそうそうない。欲しいのは、リブートより確実で迅速なサービス復旧手法なだけです。
>つまり、お前さんのところは舐められてるってことだ。
いやはや、逃げ口上がこれだ...wwww代案提示できない、解析もロクに出来ないクズ連中だと、ダメダメですね。ま、運用者としては粛々と正しく、「低能なエンジニアが対応できない」ということでやっているだけですから、問題ありません。エンジニアさんたちへの糾弾は今も続いておりまして、5年前の課題についても「なぜ究明できないのか?」を説明、というか進捗報告のために、毎月遠路おこしいただいております。費用的には、あちら持ちだそうで、そういった50件ほどの「解明できなかったごめんなさい、何年でも謝ります」みたいなことになっちゃう。ちゃんと求めた資料全部やったんだから、解明しちゃえばいいのにねぇ、無能だとだめみたいですね。
>逃げときゃいいやと思われてるから舐められてるわけですが。
逃げになってなかったりしますなぁ。代替予備機の無償提供で逃げるというのは、むしろ戦利品としてありがたいな。
>そんな「クズ連中」に仕事を発注した人に責任とってもらえよ。
うん、そのマネージャさんがいらっしゃっていますよ
>責任が外部にあればいい、身内の無能さは問題にされない・・・すばらしい企業文化ですね。
いえいえ、責任の所在を解明できていないので、解明してくださいね。それが約束でしたからね..ということでしかありません。ビジネスを甘く見てはだめですよ。
>気持ちよくベンダなじってたらうっかり自分(の会社)の無能を晒しちゃっただけなんだよ。
なじるだなんて...責任をとってもらっているだけですよ。こちらは普通に仕事していますので、問題ありません。損害額もあちらの保険で払ってもらったこともありますので、なんとかやっているわけです。
>あるいはろくに考えもせず盛り過ぎちゃったか。どっちにしろアホなことに変わりはない。
まぁ、確かに、ログとっても解析できない上に代替案を提示できないアホがいたということなんですけどね。
>そのマネージャは、cmさんの会社の人間ですか?
別会社の人ですね。あ、似た様に未解決の問題について定期的に配下の人間を連れてこられる社内のマネージャもおりますな。解析結果がでないのに、なぜダンプを要求したのか?といったことを説明できない上に、無駄に遅延させる愚策以上を提案できないままなので、定期的に会議にて進捗状況の説明をしていただいております。
解明について進捗がない件については、「進捗させるためのアイデアを毎月一個は提示して実行」ということで、ベンダーさんも交えて解明作業を続けていただいておりますね。無駄に遅延しない(つまり解明できる)手段の提示も、毎会議ごとに提案するか、ちゃんとダンプやら指定されていた情報で確実に解明する体制を検討いただいております。社内/社外のマネージャ様とも、2年以上にわたって解明作業と、解明できないなら解明できる体制/機構の確立を部門費用/相手様企業費用にてお願いしております。
どういった体制/機構なら出来るのか?が毎回提示される案が曖昧だとか、これでちゃんと解明できる理屈が説明できていないとか、その体制で以前提示したものが解明できるかやって検証してください、出来なければ意味がない提案でしかないですよ、とかいった突っ込みで粉砕しちゃっているわけです。
まぁ、わたしの携わっている業務関係にいるのは、大手ベンダー各社様も結構いてるのですが、なぜか、そういったヘタレな自称エンジニアの低能力なお方ばかりで、我が身の不運を呪ってしまいそうです。
このトピックを通読しても、代替案を出さないで、再起動のまずいところを言うだけの低能自称エンジニアレベルの方がと似たことを言っている輩が多くいる様に見えます。もしかして、/.Jではエンジニアさんは参加されていなくて、アマチュア坊やだけなのかなぁ?と危惧します。
いやいや、そんな低能ばかりでもないでしょう。完全に解明しつづけていらっしゃるのでしょうね。そうでなければ、代替案なんかいらないわけですからね。それはすごいのですが、あいにくと業界歴30年ほどですが、まだそういった方とはお会いしたことがない。
出来たら実績とか開示してもらえるとありがたい次第です。
まさか、解明を任せて100%近い究明を出来ない程度で代替案も提示できないで、時間を無駄にしたい馬鹿ばかりではないと思うので...
>そんなことで予算を浮かしたら、次の更新のときに予算が取れないんじゃない?
いえいえ、そのままリプレース作業に入ります。決裁もそのまま新たに起こす。代替機によるリプレース開始時期が遅くなるけど、サポート代金は貰えますので、損はないですからね。
>前回と同じようにタダでゲットしろって言われそう。
そうそうそんなおいしい事が起こっていたら決裁関係は楽なんですけどね。
>cmさんの会社で「別会社」を選んで仕事を発注した人に責任をとってもらうべきでしょう。
ちゃんとSLAなんかでやるといっていたことをやらない低能なエンジニア(自称)とそれを擁立している馬鹿会社の問題だからねぇ。まぁ、次の契約では、面白いことになっていたりするよ。サービス提供できない場合に原因究明責任がより原核なのになったりね。
>商売でつきあう相手の低能っぷりを嘆くようでは、あなたも低能のお仲間なのでしょう。
ちゃんとリブートで復帰していますが、なにか?リブートを邪魔している「代替案提供できない」糞の仲間ですか?
>無駄な会議やって嫌がらせしてるようじゃ、とても、あなたが有能とは思えない。
結構、その会議で「ダンプなどの無駄さ」「従来サポートと賞する低能集団の馬鹿さの露呈」といったことが判ってきていますので、そう無駄でもない。低能な馬鹿、つまり自称エンジニアちゃんたちの化けの皮をはいでいって、代替案がない以上は、リブートということになっているだけのことですよ。
あ、わたしは有能ではありませんが、代替案も出さない馬鹿を馬鹿だと判る程度の普通なレベルです。代替案を出さないでぐちゃぐちゃ言う低能な君よりはずっと上ですが、低能レベルより上ってことでは、有能とはいえません、それは確かです。低能愚劣な方を排除しないことには、駄目なんですよ。
マネージャーだけ別会社から連れてくる訳ないじゃない。この方が「別会社から連れて来られた人」なんですよ。その背景を理解して読めば客先とベンダーの間に立たされて苦労なさってる立場がよく理解できますよ。
>なに問題をすり替えてるんだよ。
そうですよね、代替案も出せない糞が喚いているのがおかしいですよね。解析しました、わかりませんでした..その回答まで早くて三日。三日もサーバ寝かせておけって...一日あたりいくらかなぁ。ACちゃんらが使わせてもらっているPC程度と勘違いしているのかもしれませんね。
>あなたとあなたの会社の問題を、他社の問題にすり替えている、って言ってるの。
相手の会社の問題ですからね。それに対して、被害が少なくなる様に提案して施策/実行しております。その一環で、駄目なベンダーの駄目さを指摘し、それが改善がない以上、自力で「馬鹿がいうリブートは相手にしない様にしましょう」提案からそれが受け入れられるということなんですよ。
>優良な案件には見えませんね。
まぁ、そういう案件もあるね。そうでない案件もある。そういった案件を含めて、出来るだけ安全に回すというのがお仕事だからね。代案もだせないクズが何か言っても、ほんと無駄なんですよね。
>進捗しないと分かっているのに進捗を報告させて糾弾するような、
ほんと、あのベンダーから、「これはもう出来ません、解析できるといったのは嘘でした、許してください。今後はこういう方策/機構でやればずっとよくなります」といった提案があれば、よいのですけどね。
>十分なスキルと妥当な要件でもって仕事を発注すべきなんですよ
はい、弊社にはそれなりスキルもありますし、馬鹿ベンダーの言う嘘を訂正していたりしますから、それなりにやっていますね。で、代案はあるのかな?どうも、あなたもそういった糞な低能ベンダーさんの肩を持ちたいみたいですね。もしかして、中の人?
>UNIXはサーバ再起動しなくても復旧できる方法は必ずある!そんなのできるの生きたままシステムにアタッチしてライブデバッグできる物だけじゃないの?(カーネルにライブパッチあてるとかできた?)UNIXにはなかったと思うしSymbolicsとDEC System20以外あんまり有名なの無いような?
最悪プロセス再起動でなおせって事じゃ無い?
Unixだと再起動しなくていいというのは、多くの場合、問題となっているプロセス/デーモンが自明で、それらの再起動でサービスを続けられるからでしょ。他のプロセスに影響を与えていることが少ない。画面(X-Window)が固まっても、シリアルなり、SSHなりでログインすれば大抵は(目先の問題は)解決する。それと、Unixだとコマンドラインが基本で、それのGUI版があるという感じなのでコマンドラインも使いやすい。Windows版だとそれが逆だから、コンソールによる操作はイマイチ。
あと、大抵はWindowsクライアントと比較している気がする。Windowsクライアントで画面が固まってしまうとリセットするしかないことが多いが、Unix系だとクライアントでもコンソール以外にシリアルやsshでも使えるようにセットアップしていることが多いとか。
>最悪プロセス再起動でなおせって事じゃ無い?
カーネルとかあたりでメモリーリークがあると、無理。デバイスにプロセス張り付きがあると、プロセス再起動が出来ないこともある。動いているkmemに直接パッチをあてるという手もあるが、影響範囲探索をリブート想定時間内に行うのは無理。HW障害の可能性もある場合、動作不安定になっているシステムではその調査も不安定。
たぶん、最初の「UNIXはサーバ再起動しなくても復旧できる方法は必ずある!」は、「幸せは必ずある!」といったメルヘンおつむなお方の発想でしょう。
幸せを求めて無駄な時間を艱難辛苦の中で過ごし、挙げ句にボロボロになって何も得られずにくたばるタイプではないかと...
# サーバ再起動しなくても復旧できる方法を探しに旅立った青年の話とか...www
>CGIで書かれたプログラムの問題でApacheのゾンビが大量発生したら、
NFSを動いている時に切り離されると、ファイルロックされちゃってプロセス張り付きとかもあってね。で、ロック解除まで待っているよりリブートの方が早いという場合もある。なので、そういったことまで調べていると、時間がかかっちゃうので、リブートという判断もある。
君の様な、色々ありえるのを「再起動で治ると思われる」と即断しちゃうレベルのお方もいるにはいますがね。過去事例が少ないとか、経験がすくないと、そういった即断をしがちなんですよね。
>UNIXかWindowsかの違いじゃなくて、管理者の質の差だよ。
まさにそうですね。あなたは、そのよい例を示してくれました。
ビット化け、特にカーネル管理領域のメモリビットが化ければWindowsもUNIXも関係なく、再起動行き。化けたデータでシステムの一部が上書きされた可能性があるならOSが何であれ再構築も視野に入れる。一過性の問題をピンポイントで復旧するか再起動で一括処理するかは、復旧までの時間的猶予と情報収集の必要性で決まることで、やはりOSは無関係。再起動で一括処理した場合でも再発防止の必要性に応じて原因追及すべきだし、再発防止の必要性が原因追究に必要な労力を上回る見込みなら原因追及を放棄するのも、やはりOSに関係しない話。
重要度の低いクライアント用途でWindowsが使われることが多いからって、それをOS自体の特性に含めちゃダメ
# さすがに宇宙用途レベルの対障害性OSは考慮してませんが
>メモリビットが化ければWindowsもUNIXも関係なく、再起動行き。
しかし、それで動いて、ダメダメになっちゃうのもある。そういった例を知らないあなたは所詮はど素人?
>一過性の問題をピンポイントで復旧するか..
以下、ど素人が何かいっているな?レベルで次にいくよ...www
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>UNIXはサーバ再起動しなくても復旧できる方法は必ずある!
いや、具体的にその方法を示しているところがないだけだ。
某BMも某UNも某Pも、さらに某立/某通/某ECさんも「待てば究明してくれて、確実に対処方法だしてくれるんですね?出せなかったら会社潰してくれますね?」と聞くと逃げる。
優秀なエンジニアさんだと、さそれがきっと出来るのだろう。
しかし、優秀なエンジニアさんは、今のところいない様にも思える。
どなたかご紹介いただけますか?...www
Re: (スコア:0)
運用を顧みないワークアラウンド提示する奴もいっぱいいるけどね!
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>客にそこまで迫られたらワークアラウンドを見つける方に舵切りますけどねぇ。
実は客もそこらへんは知っているので、「サービスを無駄に止める可能性が高いダンプや自称エンジニアによる調査」は説得力を失っていたりする。
ある意味、調べるために!とか言っている方々がほしがっているものをわざわざ与えたとしても、ほしがっている方々の技術では無意味だということなのでしょう。
Re: (スコア:0)
ワークアラウンドなんかある程度状況がつかめてないと出せない場合が多いし(運用を変えるならともかく)。
だいたい技術者だけじゃなくそんなこと言われる条件で契約する営業も業務もアホだ。
契約外なら「無理」の一言で返すだけなのに。外れ会社だよそれ。
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>そんな浅い調査しか出来ないところから買うのをやめたほうがいい。
そうでしたら、SUN/CTC/HP/IBM各社さんから買うのをやめていらっしゃるのでしょうね。
あ、そうそう、RedHatさんもだな。
>ワークアラウンドなんかある程度状況がつかめてないと出せない場合が多いし(運用を変えるならともかく)。
もちろん、ダンプやらログやら提出、最悪、エンジニア派遣していただいての調査とかね。
しかし、それでフリーズの原因が究明されるまでそのままとか、無理でしょうなぁ。
よほど、止まってもよいサーバのお仕事だけされていらっしゃるのでしょうね、うらやましいな。
>契約外なら「無理」の一言で返すだけなのに。外れ会社だよそれ。
実際、営業さんなんか、「我が社で調査して解明します」とかおっしゃるわけで、それが出来るといいね。
Re: (スコア:0)
別に、ベンダがSLAやら契約やらに違反しても損害賠償する必要はあるけど、会社たたんだり社員やめさせたりする義務も義理もないわけで。
こっちもそこまで口出せるわけないですし。
#そもそも、調査はわからないからするもので、結果がでることがわかってるなら誰も調査しません。
#結果がでることがわかっているなら、機械的に判定するだけです。
あと、サービスに影響出したくない気持ちもわかりますが、できるだけ情報提供は続けたほうがよいですよ。
ベンダさん
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>そもそも、調査はわからないからするもので、結果がでることがわかってるなら誰も調査しません。
で、実績としてダンプを時間をかけて取るというのが無駄だということ。
解析できる確率が低すぎる上に、停止時間への影響が大きい。
SLAなどでは障害からフェイルオーバに何分と示してあるのに、情報収集だけでそれを上回る時間を必要としちゃう。
SLAに調査のための時間を加味せずに締結しておいて、後から「調査のための時間」を別枠だとか思っている馬鹿がいるってのが問題。
約束通りにちゃんとやれ、出来ない約束をしたら、出来るまで糾弾する、面倒なんで潰れてくれない?というのもあるわけな。
>結局こちらのシステム部門の設定ミスでした、なんてこともありましたし。
それはそれで原因究明できたわけで、めでたいのでは?
それが出来るのは、結構なことだと思います。
>そこら辺をしっかり説明できないのは、ベンダに「技術」がないからだと言えばそのとおりですが。
解明しますと言っておきながら、解明できない。
解析します、で、ぜんぜん役にたたない。
「弊社の技術にて解析」は、御社の無能を示すものでしかありませんな..といったところです。
解析成功確率を示して、それだけ低ければいらね..と最初からあきらめがつけさせてもらえると、ありがたい。
所詮は、無能なのですから、無能だと最初から言って無能には荷が重いというか無理な契約はしてほしくないんですよね。
無能相手にちゃんとしたアウトプットを出す様に指示するための会議とか、ほんと無駄なことになる。
あの無能連中(自称エンジニア)のために、優秀だとは言わないが普通レベル程度の方々の時間を無駄にしたくないんだ。
Re: (スコア:0)
> 「ダンプとってください」「ダンプとっても判らない場合、引責してもらえますね?」に、「はい、首を賭けて解明します」という回答を貰ったことがない。
や、
> 「出せなかったら会社潰してくれますね?」
なんて事を思いつく人自らがやるべきですね。
Re: (スコア:0)
それに
> ダンプとっても判らない場合、引責してもらえますね?
こういう発言の時点でトラブル解析の知識の無い人なのは明白なので、自らやるなんてそもそもできるはず無いですね。
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>こういう発言の時点でトラブル解析の知識の無い人なのは明白
明白なのは、実績からするとトラブル解析に無意味な情報収集でサービス停止時間を無駄に増やそうとする馬鹿を排除しているだけですよ。
Re: (スコア:0)
いやそんなアホなことを言うレベルの金をまず積んでるのか興味がある
きっとそこの会社を買い取り出来るレベルの金を今まで払ってきたのだろう
だいたい首きってOKなんて言う客はまずいない
そんな責任の取り方されても全く問題の解消にはならないからね
まぁ、そんな気楽な事を要求出来る分下っ端なんだろうなぁとは思うけどw
上の方の人はそんな事してもらっても何にも美味しくないし
そんな要求することもないでしょうなw
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>いやそんなアホなことを言うレベルの金をまず積んでるのか興味がある
いえいえ、全責任を持ちます、SLAでサービスダウンを1時間以内を目標とします..があるからね。
いくら金を積んでいるか?ではなくて、契約とかSLAの問題。
というか、SLAを守れない様な技術で開発に応じた側の問題でしかないわけです。
>そんな気楽な事を要求出来る分下っ端なんだろうなぁとは思うけどw
運用維持のマネージャさんとかも同じでしたね。
そして、顧客もね。開発とベンダーが反論したけど、実績が糞すぎて相手にしてもらえないだけのこと。
当然、無能でも発言権はあったりするので、そいつらの実績で詰んでしまうだけのことです。
そういったクズ相手している閑もそうそうない。
欲しいのは、リブートより確実で迅速なサービス復旧手法なだけです。
Re: (スコア:0)
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>つまり、お前さんのところは舐められてるってことだ。
いやはや、逃げ口上がこれだ...wwww
代案提示できない、解析もロクに出来ないクズ連中だと、ダメダメですね。
ま、運用者としては粛々と正しく、「低能なエンジニアが対応できない」ということでやっているだけですから、問題ありません。
エンジニアさんたちへの糾弾は今も続いておりまして、5年前の課題についても「なぜ究明できないのか?」を説明、というか進捗報告のために、毎月遠路おこしいただいております。
費用的には、あちら持ちだそうで、そういった50件ほどの「解明できなかったごめんなさい、何年でも謝ります」みたいなことになっちゃう。
ちゃんと求めた資料全部やったんだから、解明しちゃえばいいのにねぇ、無能だとだめみたいですね。
Re: (スコア:0)
Re: (スコア:0)
そんな「クズ連中」に仕事を発注した人に責任とってもらえよ。
> エンジニアさんたちへの糾弾は今も続いておりまして、5年前の課題についても「なぜ究明できないのか?」を説明、というか進捗報告のために、毎月遠路おこしいただいております。
ひでーな。
責任が外部にあればいい、身内の無能さは問題にされない・・・すばらしい企業文化ですね。
Re: (スコア:0)
あるいはろくに考えもせず盛り過ぎちゃったか。どっちにしろアホなことに変わりはない。
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>逃げときゃいいやと思われてるから舐められてるわけですが。
逃げになってなかったりしますなぁ。
代替予備機の無償提供で逃げるというのは、むしろ戦利品としてありがたいな。
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>そんな「クズ連中」に仕事を発注した人に責任とってもらえよ。
うん、そのマネージャさんがいらっしゃっていますよ
>責任が外部にあればいい、身内の無能さは問題にされない・・・すばらしい企業文化ですね。
いえいえ、責任の所在を解明できていないので、解明してくださいね。
それが約束でしたからね..ということでしかありません。
ビジネスを甘く見てはだめですよ。
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>気持ちよくベンダなじってたらうっかり自分(の会社)の無能を晒しちゃっただけなんだよ。
なじるだなんて...
責任をとってもらっているだけですよ。
こちらは普通に仕事していますので、問題ありません。
損害額もあちらの保険で払ってもらったこともありますので、なんとかやっているわけです。
>あるいはろくに考えもせず盛り過ぎちゃったか。どっちにしろアホなことに変わりはない。
まぁ、確かに、ログとっても解析できない上に代替案を提示できないアホがいたということなんですけどね。
Re: (スコア:0)
前回と同じようにタダでゲットしろって言われそう。
Re: (スコア:0)
>うん、そのマネージャさんがいらっしゃっていますよ
そのマネージャは、cmさんの会社の人間ですか?
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>そのマネージャは、cmさんの会社の人間ですか?
別会社の人ですね。
あ、似た様に未解決の問題について定期的に配下の人間を連れてこられる社内のマネージャもおりますな。
解析結果がでないのに、なぜダンプを要求したのか?といったことを説明できない上に、無駄に遅延させる愚策以上を提案できないままなので、定期的に会議にて進捗状況の説明をしていただいております。
解明について進捗がない件については、「進捗させるためのアイデアを毎月一個は提示して実行」ということで、ベンダーさんも交えて解明作業を続けていただいておりますね。
無駄に遅延しない(つまり解明できる)手段の提示も、毎会議ごとに提案するか、ちゃんとダンプやら指定されていた情報で確実に解明する体制を検討いただいております。
社内/社外のマネージャ様とも、2年以上にわたって解明作業と、解明できないなら解明できる体制/機構の確立を部門費用/相手様企業費用にてお願いしております。
どういった体制/機構なら出来るのか?が毎回提示される案が曖昧だとか、これでちゃんと解明できる理屈が説明できていないとか、その体制で以前提示したものが解明できるかやって検証してください、出来なければ意味がない提案でしかないですよ、とかいった突っ込みで粉砕しちゃっているわけです。
まぁ、わたしの携わっている業務関係にいるのは、大手ベンダー各社様も結構いてるのですが、なぜか、そういったヘタレな自称エンジニアの低能力なお方ばかりで、我が身の不運を呪ってしまいそうです。
このトピックを通読しても、代替案を出さないで、再起動のまずいところを言うだけの低能自称エンジニアレベルの方がと似たことを言っている輩が多くいる様に見えます。
もしかして、/.Jではエンジニアさんは参加されていなくて、アマチュア坊やだけなのかなぁ?と危惧します。
いやいや、そんな低能ばかりでもないでしょう。
完全に解明しつづけていらっしゃるのでしょうね。
そうでなければ、代替案なんかいらないわけですからね。
それはすごいのですが、あいにくと業界歴30年ほどですが、まだそういった方とはお会いしたことがない。
出来たら実績とか開示してもらえるとありがたい次第です。
まさか、解明を任せて100%近い究明を出来ない程度で代替案も提示できないで、時間を無駄にしたい馬鹿ばかりではないと思うので...
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>そんなことで予算を浮かしたら、次の更新のときに予算が取れないんじゃない?
いえいえ、そのままリプレース作業に入ります。決裁もそのまま新たに起こす。
代替機によるリプレース開始時期が遅くなるけど、サポート代金は貰えますので、損はないですからね。
>前回と同じようにタダでゲットしろって言われそう。
そうそうそんなおいしい事が起こっていたら決裁関係は楽なんですけどね。
Re: (スコア:0)
>>>うん、そのマネージャさんがいらっしゃっていますよ
>>そのマネージャは、cmさんの会社の人間ですか?
>別会社の人ですね。
ならば、cmさんの会社で「別会社」を選んで仕事を発注した人に責任をとってもらうべきでしょう。
> 似た様に未解決の問題について定期的に配下の人間を連れてこられる社内のマネージャもおりますな。
なぜ、あなたが無能だと罵るような相手に仕事を発注しているのですか?
> なぜか、そういったヘタレな自称
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>cmさんの会社で「別会社」を選んで仕事を発注した人に責任をとってもらうべきでしょう。
ちゃんとSLAなんかでやるといっていたことをやらない低能なエンジニア(自称)とそれを擁立している馬鹿会社の問題だからねぇ。
まぁ、次の契約では、面白いことになっていたりするよ。サービス提供できない場合に原因究明責任がより原核なのになったりね。
>商売でつきあう相手の低能っぷりを嘆くようでは、あなたも低能のお仲間なのでしょう。
ちゃんとリブートで復帰していますが、なにか?
リブートを邪魔している「代替案提供できない」糞の仲間ですか?
>無駄な会議やって嫌がらせしてるようじゃ、とても、あなたが有能とは思えない。
結構、その会議で「ダンプなどの無駄さ」「従来サポートと賞する低能集団の馬鹿さの露呈」といったことが判ってきていますので、そう無駄でもない。
低能な馬鹿、つまり自称エンジニアちゃんたちの化けの皮をはいでいって、代替案がない以上は、リブートということになっているだけのことですよ。
あ、わたしは有能ではありませんが、代替案も出さない馬鹿を馬鹿だと判る程度の普通なレベルです。
代替案を出さないでぐちゃぐちゃ言う低能な君よりはずっと上ですが、低能レベルより上ってことでは、有能とはいえません、それは確かです。
低能愚劣な方を排除しないことには、駄目なんですよ。
Re: (スコア:0)
マネージャーだけ別会社から連れてくる訳ないじゃない。
この方が「別会社から連れて来られた人」なんですよ。
その背景を理解して読めば客先とベンダーの間に立たされて苦労なさってる立場がよく理解できますよ。
Re: (スコア:0)
> ちゃんとSLAなんかでやるといっていたことをやらない低能なエンジニア(自称)とそれを擁立している馬鹿会社の問題だからねぇ。
なに問題をすり替えてるんだよ。
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>なに問題をすり替えてるんだよ。
そうですよね、代替案も出せない糞が喚いているのがおかしいですよね。
解析しました、わかりませんでした..その回答まで早くて三日。
三日もサーバ寝かせておけって...一日あたりいくらかなぁ。
ACちゃんらが使わせてもらっているPC程度と勘違いしているのかもしれませんね。
Re: (スコア:0)
あなたとあなたの会社の問題を、他社の問題にすり替えている、って言ってるの。
優秀なチーム・スタッフは優良な案件に割り当て、スキルの低いチーム・スタッフは炎上しそうな案件に割り当てる傾向があります。
あなたの発言をみる限り、優良な案件には見えませんね。鬱憤晴らしや社内都合のために人を呼びつけ、進捗しないと分かっているのに進捗を報告させて糾弾するような、そんな不良ユーザーは、いずれ担当者のクビを要求してくるリスクがありますので、クビにしても構わない人を担当に付けるんですよ。だから発注側も、十分なスキルと妥当な要件でもって仕事を発注すべきなんですよ。
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>あなたとあなたの会社の問題を、他社の問題にすり替えている、って言ってるの。
相手の会社の問題ですからね。
それに対して、被害が少なくなる様に提案して施策/実行しております。
その一環で、駄目なベンダーの駄目さを指摘し、それが改善がない以上、自力で「馬鹿がいうリブートは相手にしない様にしましょう」提案からそれが受け入れられるということなんですよ。
>優良な案件には見えませんね。
まぁ、そういう案件もあるね。
そうでない案件もある。そういった案件を含めて、出来るだけ安全に回すというのがお仕事だからね。
代案もだせないクズが何か言っても、ほんと無駄なんですよね。
>進捗しないと分かっているのに進捗を報告させて糾弾するような、
ほんと、あのベンダーから、「これはもう出来ません、解析できるといったのは嘘でした、許してください。今後はこういう方策/機構でやればずっとよくなります」といった提案があれば、よいのですけどね。
>十分なスキルと妥当な要件でもって仕事を発注すべきなんですよ
はい、弊社にはそれなりスキルもありますし、馬鹿ベンダーの言う嘘を訂正していたりしますから、それなりにやっていますね。
で、代案はあるのかな?
どうも、あなたもそういった糞な低能ベンダーさんの肩を持ちたいみたいですね。
もしかして、中の人?
Re: (スコア:0)
>UNIXはサーバ再起動しなくても復旧できる方法は必ずある!
そんなのできるの生きたままシステムにアタッチしてライブデバッグできる物だけじゃないの?(カーネルにライブパッチあてるとかできた?)
UNIXにはなかったと思うしSymbolicsとDEC System20以外あんまり有名なの無いような?
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
最悪プロセス再起動でなおせって事じゃ無い?
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:2)
Unixだと再起動しなくていいというのは、多くの場合、問題となっているプロセス/デーモンが自明で、それらの再起動でサービスを続けられるからでしょ。他のプロセスに影響を与えていることが少ない。画面(X-Window)が固まっても、シリアルなり、SSHなりでログインすれば大抵は(目先の問題は)解決する。
それと、Unixだとコマンドラインが基本で、それのGUI版があるという感じなのでコマンドラインも使いやすい。Windows版だとそれが逆だから、コンソールによる操作はイマイチ。
あと、大抵はWindowsクライアントと比較している気がする。Windowsクライアントで画面が固まってしまうとリセットするしかないことが多いが、Unix系だとクライアントでもコンソール以外にシリアルやsshでも使えるようにセットアップしていることが多いとか。
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>最悪プロセス再起動でなおせって事じゃ無い?
カーネルとかあたりでメモリーリークがあると、無理。
デバイスにプロセス張り付きがあると、プロセス再起動が出来ないこともある。
動いているkmemに直接パッチをあてるという手もあるが、影響範囲探索をリブート想定時間内に行うのは無理。
HW障害の可能性もある場合、動作不安定になっているシステムではその調査も不安定。
たぶん、最初の「UNIXはサーバ再起動しなくても復旧できる方法は必ずある!」は、
「幸せは必ずある!」といったメルヘンおつむなお方の発想でしょう。
幸せを求めて無駄な時間を艱難辛苦の中で過ごし、挙げ句にボロボロになって
何も得られずにくたばるタイプではないかと...
# サーバ再起動しなくても復旧できる方法を探しに旅立った青年の話とか...www
Re: (スコア:0)
題名と本文をつなげないと成立しない文章を書くのはやめてよね。
仕事UNIXもLinuxもWindowsも使ってるけど、UNIXでも再起動しないと
どうにもならないことはあるよ。
逆に、Windowsでも、再起動で対応しているようなケースでも、本来は
再起動なしで対応できることがほとんどだ。
例えばだ、UNIXサーバ上でWWWサーバを使用しているとしよう。
CGIで書かれたプログラムの問題でApacheのゾンビが大量発生したら、
Apacheの再起動で治ると思われる。
でも
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>CGIで書かれたプログラムの問題でApacheのゾンビが大量発生したら、
NFSを動いている時に切り離されると、ファイルロックされちゃってプロセス張り付きとかもあってね。
で、ロック解除まで待っているよりリブートの方が早いという場合もある。
なので、そういったことまで調べていると、時間がかかっちゃうので、リブートという判断もある。
君の様な、色々ありえるのを「再起動で治ると思われる」と即断しちゃうレベルのお方もいるにはいますがね。
過去事例が少ないとか、経験がすくないと、そういった即断をしがちなんですよね。
>UNIXかWindowsかの違いじゃなくて、管理者の質の差だよ。
まさにそうですね。
あなたは、そのよい例を示してくれました。
Re: (スコア:0)
ビット化け、特にカーネル管理領域のメモリビットが化ければWindowsもUNIXも関係なく、再起動行き。
化けたデータでシステムの一部が上書きされた可能性があるならOSが何であれ再構築も視野に入れる。
一過性の問題をピンポイントで復旧するか再起動で一括処理するかは、復旧までの時間的猶予と情報収集の必要性で決まることで、やはりOSは無関係。
再起動で一括処理した場合でも再発防止の必要性に応じて原因追及すべきだし、再発防止の必要性が原因追究に必要な労力を上回る見込みなら原因追及を放棄するのも、やはりOSに関係しない話。
重要度の低いクライアント用途でWindowsが使われることが多いからって、それをOS自体の特性に含めちゃダメ
# さすがに宇宙用途レベルの対障害性OSは考慮してませんが
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>メモリビットが化ければWindowsもUNIXも関係なく、再起動行き。
しかし、それで動いて、ダメダメになっちゃうのもある。そういった例を知らないあなたは所詮はど素人?
>一過性の問題をピンポイントで復旧するか..
以下、ど素人が何かいっているな?レベルで次にいくよ...www