プログラマーって正直もったいないよなぁ

沙耶さんは設計のほうが世界作ってる感があるなぁｗｗｗｗｗ
ねとわくとかのインフラ設計して思った通りにハマった瞬間なんてちんこからなんか出るわｗｗｗｗｗ

これはアレよな、構築がスキーって言ってるって話だと思うんだ。


まあPGっつってもコーダーなのか設計までやってるのかによってだいぶ違うんじゃないの。
そっちの世界に浸かってるわけじゃないから傍で見てて、って感じだけどね。

インフラの世界だと基本的に（これはソフトウェアも同じだと思うけど）
・設計
・構築
・運用
の３フェーズに基本分類します。

設計は設計。要するに設計図描く。ドキュメントも書く。マニュアルも作る。
構築は設計にしたがって作る。
運用は作られたものを安定稼働させ続ける。

おーざっぱね、おーざっぱー。PGだとコード書くのは構築のフェーズなんですが、ぶっちゃけさぁ。
設計しっかり作れてれば、コードってだいたい同じようなトコに落ち着くんじゃね？
セオリーパターンってだいたい決まってるしさ。
モジュール単位でクラスの書き方のルールがあって、みたいなトコで変わるけどさ、本質的なロジックがそう大きく変わるなんて思ってない。表現型が違うってだけの話じゃないか？
まーどのアルゴリズム使うか、とかは構築なのかな。
全体のファイル構造とか、Require/Includeの入れ子とか、そのへんのチェーンの仕方とかは、たまにおー。おもしろーいなんて思ったりすることあるけど、こっちは全部設計だよね。

無論この辺はインフラにも言えた話で、～やって～やって～つくる、みたいなセオリーパターンが在るわけです。まあわりと作る人の好みの側面も在るんだけどｗ

例えばWebインフラのベーシックパターンとしては、LAMP環境が在るよね。
Linux+Apache+MySQL+PHP。

単一サーバで作ることもあるしひどいとこだとXAMPP入れりゃそれでいいだろ的な事言い出しててｹﾞﾝﾅﾘすることもあるけど、沙耶さんが好きなのは。

グローバルIP持ってるエリアにロードバランサーｘ２
メッシュでつないでリバースプロキシ噛ませるか、もしくはWebサーバのフロントエンドを複数台直。
その後ろにSQLの更新系マスターと子ノード。SQLとWebにストレージを別立てで接続。

まーSQLの更新系マスタがSPFだよねー。って感じ。MySQLって言われた時点で商用ライセンス買ってくれなかったらこのSPFは避けようがない。PostgreSQLで、っていうならpgpoolとかで更新系の多重化が選択出来るのだけど。

例えば、こういう構造にする場合、何を狙っているか、って話。

ここで考えているのは、構築の時の手間暇がかかるかかからないか。


「ではありません」


設計フェーズが最も意識して置かなければならないフェーズは、運用フェーズです。
構築フェーズなんてインフラサイドだとイニシャルとリプレースの際に集中するので、単発のコストですしね。

例えばこのうちの一台が故障した時に、いかにサービスを無停止で修復するか。あるいはダウンタイムをどれだけ最小化出来るか。設計フェーズに求められるのは実は運用部分へどれだけ意識を向けられているか、だと思うのです。

機能別にサーバを分離するメリットはまさにそこにあります。また、トラブルシュートもし易いのです。単機能で機能しているサーバはそこにつながらない状態だったら即壊れてるとジャッジしてしまえるので。

運用フェーズに置いてもっとも楽ちんな対処として、壊れたものはとっかえちゃえ。というオペがあります。ていうかそれが基本です。むしろそこにしか収束しませんｗ
要するに故障なり停止なりしちゃったものは、何らかの設定的な瑕疵が在るのでなければ、基本同じ設定で機械とっかえちゃえば治る、のです。設定的な瑕疵なんて、余程じゃなけりゃ設計段階と構築フェーズで潰しています。エージングしないと見えてこないバグ（2000年1月1日になった時だけ誤動作、なんてのはエージングしてても見つかりっこない）なんかはそもそもエージングしとくだけの話ですしね。

この場合、初期値と全く同じ設定を展開するスクリプトなりディスクイメージなりを用意しておけば、運用スタッフはそれほど専門の知識を必要とせずにこの修復オペレーションを実施出来ます。

あとはサーバのほうで機械が交換されて初期化されることがあるので、それに対応出来る、ように作っとけば良い。
このへんの考え方は基本RAIDなんかと一緒ですね。それがもちっと複雑化します。


要するに、本来運用フェーズのオペレーション要員に高コストな技術者を当て込まない、が基本ですね。なぜなら運用オペは24×365を求められますし、そんなとこに設定の修正対応やらOSの基本動作含めてガチガチの技術屋を雇ってシフト運用するってのは正直ぶっちゃけありえなーいｗｗｗｗって感じの世界です。

インフラの運用オペの募集がほぼ未経験者OK！なのは設計と構築でほぼ運用オペを作業にまで落とし込んでいるためです。
逆に運用オペで技術が要るみたいなこと言ってるトコは設計構築フェーズにできることがまだいっぱいある、ってことなのです。たいていがイニシャルの段階に時間をかけられなかったとかめんどくさかったとかそんな理由で。


これはWebアプリでいやあ、CMSを作るとして、その機能だとかUIだとかの設計フェーズのSE、それをコードに構築してくPG、じゃあ運用ってなぁに。って要するに記事書いてアップすることだよｗｗｗ
まあそれ以外にもCMSがログ吐いたり機能としてトラックバックとかもってたりデザインテンプレートとかあったらそれを修正できたり、ってのも求められるけどね。
それでもプログラムガチガチに書けるPG、を求められたりはしないでしょう。
テンプレートにphp使ったりするので、その辺を知ってる人、みたいな要望は在るでしょうが。


逆に、CMSが未完成で管理画面ではBlog記事しか書くことができず、デザインの修正はphpコードの中に埋め込まれているHTMLを逐次修正しなければならないWEBアプリ。

運用フェーズで技術が要るケースってそういうことです。設計と構築でまだやるべきことが在るでしょうって話。

イントラの業務系処理ならVBA使える人ーとかね。本来はその程度の話だと思うのですけどね。

なお、インフラ屋も基本的に中規模程度の案件までならサーバもネットワークもごたまぜにして設計フェーズにブチ込みますが、大規模だとサーバインフラの設計とねとわくインフラの設計を分離しないと（主にネトワク屋が）脳みそばーんしますｗ

ネットワークってのは論理構造と物理構造の二重レイヤで構成されている上にそれぞれの相互影響も強いので、わりと存在自体がスパゲッティ。
ルーティングプロトコルである程度自動化するにしても、上位ASネットワークですらこのルーティングミスる世界ですからね。
まあミスってても本来は相手に届くようにメッシュになってるわけですが、吸い込まれるようなミスをしてしまったら堰き止めますしね、そうなると”通信が不安定”という状態になるわけです。

ちょっと複雑系のルーティングテーブルとパケットのフィルタルールをVLAN込みの多重構造ネットワークで数箇所のルータの設計して、設定つくってミスナシ一発で当て込めたりした日にはなんか出るわ。

ただまあね、世の中そんな綺麗にはなってくれて無くて。


構築フェーズが実際にモノを作るので、設計フェーズと混濁するんだ。
構築フェーズやってる連中が作りながら設計図を作ったりね。まあそれはそれで決して悪いとは思わない。

ただ、作り手側が自分の今やっている作業が、構築フェーズのものなのか、設計フェーズのものなのかは理解しているべきじゃないかな。
その区分が作り手にもないから、クライアントの要求に対して設計の修正を含む変更なのか、構築フェーズでの対応だけでどうにかなるのか、の区分がつかなくなるんじゃないだろうか。

本来SEってのはこの上流工程の設計を行うエンジニアであって、営業のことじゃないんだ。

SEがクライアントと折衝して設計して、構築フェーズに流す。これが基本のフローになって、初めてSEは意味を持つ。構築フェーズへの修正にはかならず一端この設計フェーズのチェックを通す。設計フェーズに変更があるかないかは問わない。

ま、アジャイル開発とかになると主体がPG、に移るからまた見え方が変わるよね。どっちかってーとこれは分散開発の視点だろうし。

そもそもインフラのアジャイル開発なんてやった日には一瞬でインフラが破綻するようにしか思えない。怖いｗ　日々VLANの構造やルーティングがインクリメンタルされるとか脳がついていかないからやめて！ｗｗｗｗ