インフラ全般

私なんてDevOpsを語るなんて恐れ多いのですが、

開発と運用に関わらず利害関係を持つすべてが抱えるギャップをどう埋めるかを取り決めるルール

という解釈を持っています。

インフラエンジニアとの関わりだと事業責任者と開発チームなのですが、

大きく考えちゃうと始めることが出来なさそうなので、ポイントを絞ってそこから始めてみようと考えています。

※すみません。偉そうなこといって、まだ、始まってないのです。もちろん一部はできているのですが。

そのポイントとは「フィードバック」です。

インフラエンジニアチームから開発チームにだと、
いかにタイムリーにインフラの状況を伝えるかになるかと思います。

サーバのリソース、レスポンスタイム、スローログなど、
短いサイクルもしくはリアルタイムにフィードバックすることはサービスの改善につながり顧客満足度の向上につながります。

結果、事業責任者にも満足したものになる。

ただ、きちんとしたKPIを設定しないと形だけのものになりそうなので、

フィードバックに対してどのようなアクションを取るのか。
そのアクションはどんな効果があったのかの評価を規定しておいたほうが良いと思います。

ポイント絞りすぎですかね?

皆さんってどんな解釈でどんな始め方なんでしょうか。

インフラ全般

世界陸上モスクワ2013の100m決勝を待っている間に小ネタを

短いサイクルを繰り返すアジャイル開発をインフラで取り入れるということは、

すなわちアプリの機能の追加や仕様の変更などで生じるサーバリソースの変化に

どのように適応させるのかということになるかと思います。

idcからvdcへそしてクラウドとの融合へ向けてでも書かせていただきましたが、

dmmではインフラはすべてニュートラルに考えます。ビジネスからみるとインフラに優先順位はありません。

自社環境であれ他社環境であれ、その時々の最適な環境を準備し提供します。

他社のクラウド環境を有効活用し柔軟な対応を可能とする形こそがインフラにおけるアジャイル開発なんだなと思います。

そういえば、

我々は自社のインフラを固定費、クラウドの環境を変動費として捉えるようにしています。

変動部分が安定し十分にコミットが可能となった時、

初めて自社インフラへの移行を検討すれば良いと思います。

アクセスがスパイクしそうな時はパブリック・クラウドへオフロードさせるように開発すればリリース後も安心です。

co-location

世界陸上2013モスクワ大会マラソン 福士さん銅メダルおめでとうございます。そしてありがとうございました。おちゃめなところが大好きですよ。

さて、前回、LANケーブルの記事では過去のお恥ずかしいスパゲッティ配線の写真をお見せしました。

現在もあのような配線にはなっていると思われてるかもしれないので、現在の写真を公開します。

dmmではラックの中段にスイッチを配置してその上下段にサーバを配置しています。

この写真は中段のスイッチから上段のサーバが写っているものになります。

言わなくてもわかると思いますが、左が現在、右が5年以上前です。

cur_rackスパゲッティ4

 

ケーブルは2色で電源ケーブルは短く

白はラック内の配線

緑は隣接ラックの機器との接続です。

※ちなみに緑のLANケーブルは原則2つ隣のラックまでの接続とし、それより離れたラックにある機器への接続は必ずパッチを利用することにしています。これは配線の視認性を確保するためのdmmのローカルルールです。

かなりすっきしした構成になっているのがわかると思います。

サーバの外観のチェックもモニタの接続もケーブルの確認もこれだけすっきりしていれば簡単になります。

さらにケーブル類を無理やり引っ張って確認する必要もなく、ケーブル抜栓によるオペミスも減ったところも良かった点です。

ちなみにこのラッキング、ケーブリングにもノウハウが詰まっています。これについては別の機会にお話しさせていただければと思います。

最後に管理情報に間違いがあってはならないとする運用が本当に必要なのかどうか。

間違いがあったときはミスを取り戻すのに最初からの調査と運用の見直しが検討される。

正直、このやり方だと時間がいくらあっても足りないのが現状です。

本来の仕事がままならなくなっちゃいます。

優先順位の低い仕事に優秀なエンジニアがつきっきりになるくらいなら管理しない方法を模索したほうがいいのではないかという我々の結論です。

みなさんも、

そもそも、その管理は自社の運用にとって本当に必要なのかどうか自問自答してみてください。

別の世界が見えてくるかもしれません。

co-location

とある、丸の内にあるビルの一角地下深くにそのデータセンターはありました。

もともと、回線事業者向けの仕様で作られたようなのですが、スペースに余裕があった場所をサービス事業者向けに解放したところを我々が借りる事になりました。

当時としては、ラック当たり60Aが利用ができるという事は珍しく、価格の安さもあって、即決したのを覚えています。

これはコンテンツ系のサーバにピッタリだとここぞとばかりにギリギリまで搭載。サーバルームは一気に真夏日、一部猛暑日を観測した場所もあったほどです。

まあ、猛暑日が毎日続くのですから、人間どころかサーバも熱中症です。

かといって、契約期間を残しサーバの台数を減らせば他所を使った方がよくなってしまうので、なんともし難い。

そこで考えたのが、サーキュレーター

ボルネードを三台くらい設置して空気の流れを作ろうと。

ところが、これでも全く効果がない。

そこで家庭用のおおがたの扇風機を秋葉原で買ってきて設置。これも改善せず。

結局、工業用の扇風機を二台導入し、強制的にすべての地域で真夏日になるように調整。

これで、二年ほど運用したのですが、流石にハードディスクの故障率は半端なかった。

いつもピーピーなってた記憶があります。

さあ、この教訓からdmmでは、

契約する電流での温度を保障(SLA)し、問題があっても積極的に対応を確約いただける会社様を選択させて頂いております。

今では、データセンターもかなり進化してきてはいますが、今も昔も、問題あった時に積極的な対応ができるかどうかだと思います。

wifi, 小ネタ

interop2013のセミナーで教えていただいたのですが

みなさんご存知でしたか?

wifiのチャンネルは周波数が低ければ低いほど外部の影響(例えば電子レンジ)を受けにくく1chがベストだとのこと。

「よし、1chを利用しよう」思ったら周りのwifiがすでに、、、

また、面白いなと思ったのが

wifiから遠くの端末が接続していると近くの端末も遅くなってしまう傾向があるようです。

1階のリビングにwifiルータがあったとして、

リビングでwifiを使っている人と2階の部屋でwifiを使っている人がいた場合リビングの人の速度に影響がある。

小ネタでした。

PAGE TOP