つぶやき
技術系や雑感等は再編集して本文の記事にする事を前提としているので、こっちにLinkを張らないでください。
Facebookに書いた駄文(20150203)
相変わらずグダグダな、整理できてないことを書いてみる。
インターネットのインフラに絡んで、はや25年になる。 この間の技術の進歩の話は置いておいて、今は運用のことを。セキュリティのコンテクストの中で、今日運用の話を幾つか見かけたので、も少し全体的な運用について書きたくなったから。
インターネットに接続されているシステムにおいて、運用は常に「後回し」にされ、顧みられることは少ない、しかしながら非常に大切な機能であると思う。
この「運用」ってやつは、利用者から見えない事が最も重要な事であって、「運用が見える=何らかの問題がある」事態であるわけです。これが意味することは、「利用者のみならず、システムを保持している者」にとっても、運用が見えなくなるということです。 また、「運用」という行為は、非常にチマチマした、わからない人が見たら「何の意味があるのかわからない」作業の集合体であるということです。 なので、運用経験のない人から見ると「無駄の塊」に見えるし、個々の作業が細いから「全体の行為内容にかかる作業量」が把握出来ず、むしろ、個々の小さい作業に引きずられて作業量を少なく見積もられがちになります。その結果引き起こされるのが、人員削減や、維持コスト削減というやつですね。いっぱい見てきました。
加えて、システムを作る側は、運用経験がないか、乏しいので、「運用が楽になる」システムを構築してくれることは稀です。考慮してくれたとしても、案外的外れなものが多い。これは、システムを設計するときに、運用視点が足りないことによって引き起こされるものです。その意味で、設計者側に多くの問題があるものです。運用側に相談があることは稀だし、あっても、運用側が何をお願いすべきなのかを適切に伝えられるかという問題も、もちろんある。その上で、少なくとも日本の会社組織で、「運用を正しく理解し適切に評価している」ところは非常に少ない。
このような運用環境の中で、一つのシステムを動かし続けることというのは、並大抵の事ではありません。 だって、動かし続けてもその意味が理解されず、感謝もされず、評価もされないから。
運用というのは健康のようなものであって、病気になってから(障害が起きてから)初めてその存在に気づくものなのです。少なくとも日本の会社組織で、「運用を正しく理解し適切に評価している」ところは非常に少ない。 これは、運用者の側から見れば、本当に悲しい事で、自分がそのシステムを支えているというプライドをモチベーションにするしかない。そうでなければ、普段評価されることもなく、何かあると責められるという仕事を続けられないわけです。
こういう状況が何を産むかといえば、凝り固まった運用、責任回避的反応、その結果としての、新しいことが出来ない環境だと思うのです。
ここまで書いたことは、勿論、ある意味での極論なのですが、なぜか、この極論のような環境をしばしば見かける。 恐らくは、管理側の経験の欠如、想像力の不足、非合理な過度のプレッシャーからくるものだと思うんですね。で、運用側に甘えてしまってそこから目を背ける。 また、運用側も、恐らくは(それまでの経験からくる)恐れ、勉強・訓練不足、整理した上での説明・報告不足、諦めなどがないまぜになって、唯々諾々と従う。 これが、現在のシステム運用環境における状況ではないかと思うわけです。 (勿論、こういうところばかりではないですが)
本来、運用者ってもっと尊敬されていいと思うんですよ。運用者がもっと声をあげてもいいと思うんですよ。それができる環境が本当に必要だと思うのです。
今の日本の運用って、恐らくはオーバークオリティなんだと思う。その原因は、恐らくは世界一厳しいと言われる利用者のプレッシャーなんだと思う。でもね、厳しいのはいいけどモンスターになってはいけない。 今の運用者の置かれてる環境は、「身内の中にいるモンスター」に理不尽な要求をされて、その要求と現状の整合性を取ることができない状態なのではないかと思うのです。 システムってのは箱物ではないのだよ。箱物よりもはるかにたくさんの「維持の為の仕事」があるのだよ。
Facebookに書いた駄文(20150520)
少しだけ、思ったことを書いてみる。Security関連。 例によって、グダグダで、まとまりは無い。
数年前は、XSSだのCSRFだののようなWebアプリケーション系のセキュリティが花盛りだった。もう少し言うと、Middlewareから上のレイヤーのセキュリティ。 この状況が数年続き、そのエリアのセキュリティがビジネスに繋がってきたことから、Security技術者も、このエリアの人が増えた。知見もBad know-howも溜まった。 これはこれで素晴らしいことだとは思う。
翻ってみると、その間Infra関連技術者はApplication技術者と違ってあんまり増えていない。また、Applicaton側と比べて技術的変化が少なかった。
いまはやりのSDNだって、あれはInfra技術者側の技術ではなくApplication側の技術者向けの技術に近いと思う。
さて、この状況の中で、ShellShockや、Heartbleed、今回のracoon問題をみると、これがなかなか悩ましい。これらの問題は、少なくともApplicaton側の守備範囲からは少し離れている。むしろInfra側の守備範囲。
ところが、これらの実装は、インフラ側で対処することが困難。だって、多くのインフラ技術者って、この領域に関して言えば「提供されたupdate」を適用するしかできないから。
OSのpatch、Server applicationのpatch、FirmwareのPatch、全部根は同じ。
冪等だの青緑だの言うけど、これらは「インフラはちゃんと動く」という担保があって初めて意味を持つことであって、「インフラを動かすための技術ではない
(使えないと言っているわけではない。構成管理や冗長を考えたらこの考え方はInfraにも有用)。
Securityの観点でここしばらくのようなこと(shellshock,heartbleed,…)が起こって困る事は、そもそも、インフラ側が提供している機能の根幹であるこの種のソフトウェアは、実はApplication側に比べて、余りにもぬるま湯に浸かってたという事。そして、多様性が足りなく、置き換え困難な事。さらに、一度何かが見つかると、その影響がとんでもない範囲まで広がっていて、かつ、その修正がとんでもないコストになる事。 しかも、インフラは「動いて当たり前」と思われ、かつ、過剰な価格下落を要求されている事。
(ちと脱線) 運用者から見たら、「こんな報われない、旧態依然とした、辛い刺激しかない、激務」なんてやりたくない、と思う方が普通で、だから新しい人だって入ってこないしすぐに抜けてしまう事になると思う。 (元に戻して)
まぁ、まとまりもとりとめもないんだけど、今の状況はかなりまずいところまで来ている気がしている。善意に寄りかかった寄生虫がモンスターになっていろいろ崩壊するまえに、もう一度「Infraの総点検」と、「問題点の洗い出し」を徹底する必要があり、それを一つずつ潰していく必要があると思う。
少なくとも、Applicationエリアの近くまでInfraを引き上げないと、「共倒れ」になると思う。
メモ(20150520)
- etckeeper with ansible https://github.com/silpion/ansible-etckeeper
- pure-vi http://ex-vi.sourceforge.net
気になった記事(20150512)
ああ、気になった記事がたまっている。 FaceBookと連動できたら便利なのに… いや、FBでなくてもいつも使っているToolから直接URL送れるでもいい…
- これに気づいてない日本人は永遠に英語を話せるようにはならない。 英語を話せるようになるかどうかよりも、根本的に失礼なことをしていたということの方がはるかに悲しい
- GCEのライブマイグレーションのすごさをまとめてみた 単体レベルで考えれば、技術的には、それほどのことをしているわけではない。しかし、あの規模で確実に動くことはものすごいことだ
- 伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？ 確かに、そういう傾向かもしれないと思った
- Gitと連動するWebベースのコードレビューツール「Gerrit 2.11」リリース へぇ。今度試してみないと
- 大規模データ時代に求められる自然言語処理 -言語情報から世界を捉える- これはあとでじっくり読まないと
- Metasploit――大いなる力と責任を体感する (1/2) うむぅ。これはやりながらじゃないとわからない
- 息が止まる超絶演奏。あるピアニストの『ラ・カンパネッラ』がスゴすぎる 確かにこれはすごかった
- CC0 日本語版の公開 参照版ではなく正式版というところが素晴らしい
そろそろいろいろ片付けないと
やらなきゃならないことが山のように溜まっているので、そろそろメモにしておく。
- DNSサーバーとSMTPサーバーの移設
- KnotDNSはいいとして、Postfix+CyrusSASLで行くかPostfix+dovecotで行くか…
- IMAPサーバーの移設
- SMTPサーバーから切り離す。
- XenServerのβ版テストと、XenOrchestraのテスト
- Dom0がCentOS7になるので、その分の確認とか
- OPNsenseの試験
- イケてたら移行も考えないとなぁ
- NGiNXとmod_securityを利用したWAF構築
- NGiNX Proxy/LoadBalancer配下でWAF処理させる一連のシステムの構築
- SignatureはOWASPの奴かな
- Snort+pf+pfSyncを利用したIPSの構築
- そろそろ新しいSnort使いたいんだよな。全然追えてないけど
- NGiNXのSPDY/SNI対応と、FreeBSD/NGiNX上でAES/NIを利用したSSL Accelerator環境の構築
- SPDYは、NGiNXがHTTP2.0対応するまでのつなぎ
こうしてみるとてんこ盛りだ。全部それなりに時間がかかる。