アカウント名:
パスワード:
mixiとは別の会社の経験だけど
サーバーOSが古い→ DBMSのバージョンも古い → DBMS用に用意されている新機能が使えない
→ PHPのバージョンも古い→ PHPのフレームワークやライブラリも新しい物が使えない、 PHPのコードを書く時でさえも、非効率な書き方をする必要がある。→ 全部独自実装する必要があるが、そんな時間も金も無い。 (つか、それするくらいなら最新OSに移植した方が安くて早い。そんな人も金もないから移植さえできてないのに……)
みたいな感じで、芋づる式に次々に問題が出ていた。
他にも「動くハードウエアが手に入らなくなってきた」というのも切実な問題だった。
追記。
旧バージョンを使うことの問題は「安定稼働しない」のような形ではなく「ただ稼働させるだけでも、何倍も何十倍も手間がかかる」「新機能を実現しようとしたら最新OSの場合の何十倍~何百倍以上の金と人と時間がかかる。 このため事実上、実現不可能になる。」という「機会損失」の形で出ることの方が多い気がする。しかもこの状況は急な下り坂を転げ落ちるかのごとく、日々悪化の一途を辿る。
最初の頃は緩い下り坂で現状維持は容易いが、気がついたら急な下り坂になっていて、現状にとどまるだけのために全力を注がなければならなくなる。実に無駄な努力だ。
今あるものしか見
結果論ですか? 管理者としてそれってどうなの?
結局なんでも結果論になると思うけどね、インフラ部分は。たとえメーカー製・商用サポートOS使ったところで、逝く時は逝くだろう。完全なものはないし。そりゃ、RHELとかにしたほうが問題が起きる可能性は低いかもしれない。でも、結局可能性。Fedoraでずっと何も問題なかったならそれでいいと思うよ。管理者といってもさ、商用買って安心して、責任をサポート企業に押し付けられるからいいだけの話だろ。自社に解決できる人がいるならそれでいいんじゃね。
> 責任をサポート企業に押し付けられる
rpm とか指定pkg使う最大の理由ですよ。
> 自社に解決できる人がいるならそれでいいんじゃね。
うらやましいです。
> > 責任をサポート企業に押し付けられる>> rpm とか指定pkg使う最大の理由ですよ。たとえばmixiがセキュリティがらみの事故起こしたとして、その時に「サーバーにはRedHat純正のパッケージ使ってました」じゃ責任逃れできない気がするんですけどね。対社外的にも、対社内的にも。
障害が起きれば「そらみたことか」と言われ障害が起きなければ「結果論」と言われ
ちょっとmixiがかわいそうになってきた
ていうか、よその会社が何のサーバー使っているかなんて(自分の会社の開発委託先ででもない限り)どーでもいいよね。ほんとに自己責任の世界。
一般にサービスを提供してる会社でそんなわけないじゃん
当然、結果論だろ。机上の空論に重きを置くなら、マネージャの席には専門本でも置いとくのが一番だね。
問題を起こさなかったのなら管理者としては優秀だよ。
リスク見積りをした結果、古いOSを使い続けるリスクより、OS移行で障害が発生するリスクの方が大きいと判断したんでしょう。
我々にとっては「結果論」ですが、mixiの中の人たちにとっては「事前の想定通り」ということになります。
私はmixiの判断は正しいと思いますけどね。パフォーマンス上は問題ないわけだから、残る問題は脆弱性が発見された場合の保守ですが、これは発見されてから考えても大抵の場合は一時対応が間に合うでしょう。数年に一度発生するかしないかのトラブルのためにOS移行コストをかけるのは、ライフラインに直結しないサービスの場合、過剰だと思います。
私はmixiの判断は正しいと思いますけどね。
正しくなかったから
Q. どうせこれからもアップデートしないのでは?
A. 嘘だと思われるかもしれませんが、定期的にアップデートする予定です。
なんて言ってるんじゃないかなあ?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
何の問題が? (スコア:0)
だとしたらスラドでそれなりの頻度で話題として見かけていたはずですが、少なくともここ2、3年そういう話は聞いたことがありませんし。
Re:何の問題が? (スコア:1)
mixiとは別の会社の経験だけど
サーバーOSが古い
→ DBMSのバージョンも古い → DBMS用に用意されている新機能が使えない
→ PHPのバージョンも古い
→ PHPのフレームワークやライブラリも新しい物が使えない、
PHPのコードを書く時でさえも、非効率な書き方をする必要がある。
→ 全部独自実装する必要があるが、そんな時間も金も無い。
(つか、それするくらいなら最新OSに移植した方が安くて早い。そんな人も金もないから移植さえできてないのに……)
みたいな感じで、芋づる式に次々に問題が出ていた。
他にも「動くハードウエアが手に入らなくなってきた」というのも切実な問題だった。
Re:何の問題が? (スコア:3)
メンテ契約とかもあって、ある一社からビッグエンディアンなCPUのサーバを導入していた某社のこと。
次の四半期からビッグエンディアンCPU使用モデルは全廃止との通知受けて、導入計画の崩壊となり
一時期は計画立案関連がパニックになっていた。
サーバ側アプリがエンディアン依存で作られているのが理由だったけど。
リトルエンディアンにも対応するよう改修する時間稼ぐ為に、廃止前に可能な限り入手して自社で保管
しておくと言う荒技になったとか・・・・。
#買い置きした分の保守契約期間がどうなったかは知らない
Re: (スコア:0)
追記。
旧バージョンを使うことの問題は「安定稼働しない」のような形ではなく
「ただ稼働させるだけでも、何倍も何十倍も手間がかかる」
「新機能を実現しようとしたら最新OSの場合の何十倍~何百倍以上の金と人と時間がかかる。
このため事実上、実現不可能になる。」
という「機会損失」の形で出ることの方が多い気がする。
しかもこの状況は急な下り坂を転げ落ちるかのごとく、日々悪化の一途を辿る。
最初の頃は緩い下り坂で現状維持は容易いが、気がついたら急な下り坂になっていて、
現状にとどまるだけのために全力を注がなければならなくなる。実に無駄な努力だ。
今あるものしか見
Re: (スコア:0)
結果論ですか? 管理者としてそれってどうなの?
Re:何の問題が? (スコア:1)
結局なんでも結果論になると思うけどね、インフラ部分は。
たとえメーカー製・商用サポートOS使ったところで、逝く時は逝くだろう。完全なものはないし。
そりゃ、RHELとかにしたほうが問題が起きる可能性は低いかもしれない。でも、結局可能性。
Fedoraでずっと何も問題なかったならそれでいいと思うよ。
管理者といってもさ、商用買って安心して、責任をサポート企業に押し付けられるからいいだけの話だろ。
自社に解決できる人がいるならそれでいいんじゃね。
Re: (スコア:0)
> 責任をサポート企業に押し付けられる
rpm とか指定pkg使う最大の理由ですよ。
> 自社に解決できる人がいるならそれでいいんじゃね。
うらやましいです。
Re: (スコア:0)
> > 責任をサポート企業に押し付けられる
>
> rpm とか指定pkg使う最大の理由ですよ。
たとえばmixiがセキュリティがらみの事故起こしたとして、その時に「サーバーにはRedHat純正のパッケージ使ってました」じゃ責任逃れできない気がするんですけどね。対社外的にも、対社内的にも。
Re: (スコア:0)
障害が起きれば「そらみたことか」と言われ
障害が起きなければ「結果論」と言われ
ちょっとmixiがかわいそうになってきた
Re: (スコア:0)
ていうか、よその会社が何のサーバー使っているかなんて(自分の会社の開発委託先ででもない限り)どーでもいいよね。ほんとに自己責任の世界。
Re: (スコア:0)
一般にサービスを提供してる会社でそんなわけないじゃん
Re: (スコア:0)
当然、結果論だろ。
机上の空論に重きを置くなら、マネージャの席には専門本でも置いとくのが一番だね。問題を起こさなかったのなら管理者としては優秀だよ。
Re: (スコア:0)
リスク見積りをした結果、古いOSを使い続けるリスクより、
OS移行で障害が発生するリスクの方が大きいと判断したんでしょう。
我々にとっては「結果論」ですが、mixiの中の人たちにとっては
「事前の想定通り」ということになります。
私はmixiの判断は正しいと思いますけどね。
パフォーマンス上は問題ないわけだから、残る問題は脆弱性が
発見された場合の保守ですが、これは発見されてから考えても
大抵の場合は一時対応が間に合うでしょう。
数年に一度発生するかしないかのトラブルのためにOS移行コストを
かけるのは、ライフラインに直結しないサービスの場合、
過剰だと思います。
Re: (スコア:0)
私はmixiの判断は正しいと思いますけどね。
正しくなかったから
Q. どうせこれからもアップデートしないのでは?
A. 嘘だと思われるかもしれませんが、定期的にアップデートする予定です。
なんて言ってるんじゃないかなあ?
Re:何の問題が? (スコア:1)