• 2012年7月3日火曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2012-07-04T02:36:00-07:00&max-results=7&reverse-paginate=true

辞め

会社を辞めることになった。
  • 2012年7月1日日曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2012-07-04T02:36:00-07:00&max-results=7&reverse-paginate=true

ローズウォーター

海公園

ハニーと「海の見える丘公園」という所に行ってきた。

散歩だな。

その公園の中に「えのき亭」という喫茶店がある。
写真は店の中から庭を撮影したものだが、ご覧の通り、外国の庭園風である。
その喫茶店では、入店すると「ローズウォーター」というものが出てくるのだ。

水道水に薔薇の香水を混ぜたようなもの。

以前、氷水の入ったピッチャーにレモンの切れ端が入っている「レモンウォーター」を提供しているラーメン屋があったけど、同じことを薔薇でやるとは。
世の中にはこういうものもあるのだな。

調べてみると、世間ではサプリメント扱いで販売されているようだ。
効能を見ると、「リラックス効果」とかいう辺り、ハーブティーと似ていると思う。
しかし、ハーブティーよりは高給。

味わいや香りも繊細で、ほんの一口を口に含んで香りを楽しむという飲み方だろうか。
カップ一杯飲んでしまうハーブティーよりも上位ランクな嗜好品だろう。

男でもコーヒーや紅茶は飲む。好きな人ならハーブティーも飲むだろう。
しかし、独身野郎で「ローズウォーター」は無えわ。
普通は存在すら知らんだろ。

結婚して出かけるようになると、こういう類の物とも縁が出来るのだな。(´・ω・`)
  • 2012年6月29日金曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2012-07-04T02:36:00-07:00&max-results=7&reverse-paginate=true

もぎょ

もぎょ
  • 2012年6月26日火曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2012-07-04T02:36:00-07:00&max-results=7&reverse-paginate=true

往復

   ∧ ∧
  ( ´・ω・`) oO(・・・・。)
  _| ⊃/(___
/ └-(____/

6:00 起床
8:40 出社
9:00 会社到着
24:00 帰宅
25:00 就寝

   
  <⌒/ヽ-、___ oO(・・・・・。)
/<_/____/

  • 2012年6月25日月曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2012-07-04T02:36:00-07:00&max-results=7&reverse-paginate=true

ぶっ飛び3

ファーストサーバぶっ飛び事件の報告が上がってきたようだ。

http://support.fsv.jp/info/nw20120625_01.html

感想としては、「やってしもうたか。(´・ω・`)」といったところだ。
僕も現場の人間だから「ああ~」と思う部分がある。

原因1:脆弱性対策のための更新プログラムの不具合
脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成しており、今回も更新プログラムを作成しています。そのプログラムの記述において、ファイル削除コマンドを停止させるための記述漏れと、メンテナンスの対象となるサーバー群を指定するための記述漏れが発生していました。

これ、何か「ソフトウェアにバグでもあったのかな」って思わせるようにゴニョゴニョ書いてあるけど、ようするに「コマンドの打ち間違え」だろ。
ここに書いてある「更新プログラム」って、人が手で打ち込むコマンドを前もってスタンバイしておくだけのシロモノだから「プログラム」などと呼ぶのはおこがましい。
「下準備でミスりました」ってだけなんだから、「コマンドの打ち間違え」と何ら変わらん。

まあ、実際のところ、こういうミスはあり得るんだよな。
僕も経験がある。「あっ!?」と思ったら消えちまった、みたいな。
ウェイトレスが滑って転んで客の頭にホットコーヒーをぶっかけるようなもの。
今回、ここまでの被害になっちまったのは運が悪かったとしか……。

原因2:メンテナンス時の検証手順
メンテナンスに際しては、検証環境でまず動作確認を行うという手順が定められていましたが、プログラム実行後の動作確認を行う対象は、あくまでも当該メンテナンス対象サーバー群を確認すれば足りるとされていたため、検証環境下で対象サーバー以外に影響が及んだことの確認がないまま、動作確認上は問題なしと判定され本番環境での実施が行われました。


デグレードチェックが甘かったんだな。これも仕方が無い。(´>ω<`)
「対象サーバはAサーバです」って言ってるんだから、みんなAサーバはしっかりチェックするけど、他のBサーバやCサーバはチェックしないのよ。
他の対象外サーバのチェックまでやってたら、時間がいくらあっても足りない。
「どうしてもやって欲しいなら工数を10倍払えよ」ってことになる。
と言っても、普段から値下げ合戦している業界だから、そんなコストはとても払えない。
これは仕方無い。

ただし、これって多分、「午前中に検証環境でテストして、午後に本番適用」とか、それくらいの短期間で一気にやったんだな。一週間くらい様子を見れば気づけた可能性が高かったのに。
きっと、忙しかったのだろう。
我がサービスの場合、「ステージング環境」と呼ばれる検証環境と本番の中間ステップがあって、そこで一週間様子見することになってるから、ここは安心だな。

原因3:メンテナンス仕様
システムを含むデータのバックアップは毎朝6時に取得しております。
しかしながら、脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。


これはバックアップじゃなくて「コールドスタンバイ」って言うんだよ。(´>ω<`)
バックアップは最初から無かったのだ。。。

まあ、バックアップは出来ないから無かったんだろう。
サーバ規模が巨大になるとバックアップするのも一苦労になる。1日でバックアッププロセスが終わらないくらい負荷も出てくるから、バックアップってのはイメージより難しいのよ。
もちろん、最初からバックアップ負荷を計算して分散設計になっていれば大丈夫だけど、それだどハードウェア等の費用が2倍、3倍になっちまう。予算が無かったんだな。

だが、稼働系と待機系を同時に消したのは痛かった。
しかし、文章を見ると「昔、稼働系だけにパッチを適応して、待機系に適応するのを忘れるという障害があったことへの対応」というのがある。
コレ見ると「あちゃ~」だな。

「問題があるから何か対応しなければいけない!⇒対応したらもっと悪くなりました」

こういうことがあるんだよ。我が社でも沢山ある。
「問題に対する攻撃的姿勢だけが強烈で、改善策を出す能力が無い」って姿勢の人がいると、社内の雰囲気が悪くなって「こんなことやっても無駄だよなぁ」「何もしない方がマシだよなぁ」と大勢の社員が思いつつも、改悪を実行。
結果グダグダ。
よくある話。



以上、僕の感想を言うと、「重過失致死」
トラック運転手が居眠り運転して小学生の列に突っ込むようなもの。
そりゃ過失は過失だけど「100%防ぐ手段を示せ!!」って言われても、う~んってところ。

原発もそうだけど、やっぱ世の中に安全神話なんて無いんだな。(´・ω・`)
  • 2012年6月24日日曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2012-07-04T02:36:00-07:00&max-results=7&reverse-paginate=true

ぶっ飛び2

ファーストサーバぶっ飛び事件はまだ全容が見えないな。

いずれITproとかでも特集が組まれるだろうから、
随時追っていきたい。

それはそうと、今回の件がクラウド業界全体を揺るがすものであるのは確実だな!!

今のIT業界は「クラウド」っていう言葉自体が一人歩きしていて、
意味も分からずクラウドクラウドって言っている人も多い。
実際、クラウドって言葉の定義自体、今となってはハッキリしないものだろう。

クラウドの本当の意味はとりあえず置いておくとして、
僕の思う「クラウド」の特徴として特筆すべき点を挙げる。
それは、

クラウド:複数の企業で1台のマシンを使う。

ということだ。
それに対し、昔ながらの専用機というのは、

専用機:1つの企業で1台のマシンを使う。

となる。
僕はこの違いを重視したい。

今回、確かに大災害になったけど、これは別に

クラウド=脆弱
専用機=強固

って意味にはならんよ。
システムの保守性、完全性、強度は両者全く互角。
だから、「自分もクラウドサービス使ってる。もしかしたら自分のデータが消えるかも。」って思うのは早とちり。
安全性は変わりません。

じゃあ、何が問題なのかっていうと、
専用機をぶっ壊した場合は、その専用機を使っていた企業1社に対し賠償すれば良い。
しかし、クラウドをぶっ壊すと、今回のケースだと5000社に対し賠償となる。

5000社も相手に賠償なんて出来るわけねーだろ!!

つまり、クラウドという技術そのものは別に問題無い。
既にコストが許す限りの精一杯に十分な保守水準を達成している。

逆に言うと、コスト競争で安値合戦をするとそれだけヤバイってことだが、それは置いておいて。
とにかく、十分十分と言いつつ、やっぱり万が一って事がある。
そして、その万が一の際に、これだけ規模が大きくなると賠償が出来ない。つまり、

万が一の際に、会社が責任を負いきれないような巨大な責任を軽々しく背負ってしまう

という、経済的・法律的・政治的な部分に問題があるものだと思う。



じゃあ、どうすりゃいいの?って話になる。

天地がひっくり返っても100%絶対安全ってのを技術的に達成するのは不可能。
どうしても想定外の事態というものはある。

となれば、僕が思いつく対策というのは「保険」だな。

保険会社が企業向けに「クラウド保険」みたいなのを作って、
万が一の際は保険金で賠償出来るようにしておくこと。

鉄道業界だと、鉄道で大事故やらかした時に備えて保険が用意してあるって聞いたことがある。
同じことをIT業界向けにやってくれ。

これをやってくれれば、IT会社は

・お客様のデータは死んでも守ります。
・万が一、死んでも守れなかった場合は、保険金で賠償します。

って言えるだろ。



全く、これから未来が開けるはずだったクラウド商売に、
とんでもない冷や水がぶっかかったもんだぜ!!
  • 2012年6月23日土曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2012-07-04T02:36:00-07:00&max-results=7&reverse-paginate=true

白雪

ハニーと映画「スノーホワイト」を観てきたにゃん。

王道的なファンタジーだったな。
誰が観てもハズレが無いようなストーリーだったと思う。

次はディズニーアニメを見に行かなきゃな。