mySQL error with query INSERT INTO nucleus_NP_AccessAnalyze_UserTemp (blogid, userkey, ipaddr, hostaddr, accessdate) VALUES (1, 'XSTjFLWU', '18.118.45.162', 'ec2-18-118-45-162.us-east-2.compute.amazonaws.com', '20240508'): Data too long for column 'hostaddr' at row 1

Other サービスレベルの話 - 雑日記＆ブログ

|雑日記＆ブログ|雑Review|

雑日記＆ブログ

ツイート

2016-12-16

Other サービスレベルの話

Twitter見てたらこんなのが



色々見てきたけど、単に「想定していなかったため用意してなかった事例」ってのが多い気がする。

「運用でカバー」のカバーできる範囲は、担当者の技術力に関わるから、技術力ある人に金出すのやめる（事により安くて技術無い人に変える）事により、重大な障害が発生する事もあります。

とある現場の話だけど、サーバをカスタムして貸し出すサービスが有って。
機材貸出し、設定を顧客要求に合わせてカスタム、障害対応用に万が一OSが壊れたら復旧作業をするオプション付き。
そういうサービスで。
顧客がサーバーを構築して運用するって話で、当初の予定だと高価になるからって色々オプション削って、問題出たら都度お金払う方法にした所がありました。
予算的にそれで数年は大丈夫だったらしいです。
その頃に流石に「何も起こらない」からと、都度の予算も削ることになりました（景気悪くなって赤字になった為）。
で、それでも障害があったら対応しなきゃならんけど金が無いからお客さんが自分でやると言い出したそうです。
ところがそのお客さん、別に技術力もノウハウも持ってた訳じゃない。
さて、どうしたかというと、「今まで障害発生時に対応するマニュアルあったろ、それを寄越せ！」と言い始めたそうで・・・
（最初は別の事から話が始まったんだけど最後はここ。ノウハウとかタダで提供するわけないでしょ・・・そもそも復旧オプションにそのノウハウ費用も含まれてるんだから）

「運用でカバー」できない状態にまで金を削って人をへの金も減らして技術力ない人に変えて、最後に障害発生で運用が止まる。
この場合は「障害が起こった場合」を想定していなかったために「復旧方法を用意していなかった」事例。

「運用でカバー」は「お金をかけないための魔法の言葉」ではないのです。
posted at 23:33:00 on 2016-12-16 by 宣伝中止！ - Category: [Other]
ツイート

トラックバック

トラックバック
このエントリにトラックバックはありません
このトラックバックURLを使ってこの記事にトラックバックを送ることができます。 もしあなたのブログがトラックバック送信に対応していない場合にはこちらのフォームからトラックバックを送信することができます。.

コメント

No comments yet

コメントの追加

ランダム ピックアップ

[ゲーム スプラトゥーン2 新ステージ]
[ゲーム 艦隊これくしょん 2015夏イベ E-5丙作戦クリア！]
[Other あけましておめでとうございます]
[Other 有無ジェリア]
[Other 自転車と自動車の過失割合]
[ゲーム 艦隊これくしょん 2015春イベE-1甲作戦クリア！]
[PC 自宅サーバにSSHの不正ログインがあった]

ナビゲーション

<  2016-12  >
日月火水木金土
 
 
 
 
1
2
3
4
5
67
8
9
10
11
121314151617
18192021222324
25
262728
29
3031

ナビゲーション

最新記事

カテゴリー

最新のコメント・トラックバック

検索

ログイン

Powered by

Powered by Nucleus CMS