A Day In The Boy's Life -94ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

Smartyのテンプレート用(templates)ディレクトリは、デフォルトではSmartyを呼び出すプログラムと同一ディレクトリ内に置くことになっており、フレームワークなどを使っていない場合は大抵それはドキュメントルート以下にあることになったりします。

これは、セキュリティ上あまりよろしくないので、それをカスタマイズして任意の位置、任意のディレクトリ名へ保存できるようにしてみます。



テンプレートディレクトリを任意の場所に置くためのカスタマイズ


Smartyクラス変数 を定義したカスタムクラスを作っておけば、Smartyを使うどのPHPプログラムからも共通で呼び出せて便利です。


<?php

require_once 'Smarty.class.php';

class CustomSmarty extends Smarty {

    function CustomSmarty() {

        $base_dir          = "/path/to/tpl_files/";

// テンプレートファイル(*.tpl)を保存するディレクトリ
        $this->template_dir = $base_dir . "templates/";

// テンプレートをコンパイルしたファイルを保存するディレクトリ
        $this->compile_dir  = $base_dir . "templates_c/";

        if (!file_exists($this->compile_dir)) {
            mkdir($this->compile_dir);
        }

// コンパイルしたファイルをキャッシュするか
        $this->caching      = TRUE;

// キャッシュしたファイルを保存するディレクトリ
        $this->cache_dir    = $base_dir . "cache/";

        if ($this->caching === TRUE && !file_exists($this->cache_dir)) {
            mkdir($this->cache_dir);
        }

// Smartyのコンフィグファイルを保存するディレクトリ
        $this->config_dir   = $base_dir . "configs/";

// デバッグモードで動かす
        $this->debugging  = FALSE;
    }
}


呼び出す側では、下記のように書いておきます。


<?php

require_once 'CustomSmarty.class.php';

$smarty = new CustomSmarty();

$smarty->assign('msg', 'Hello');
$smarty->display('index.tpl');


Smartyを呼び出す書式はどのプログラムでも共通で書け、SmartyのデバッグモードのOn/Offやテンプレートのキャッシュファイルの保存ディレクトリなどをまとめて管理できたりします。


これで、下記のように呼び出すプログラム(index.php)とテンプレートファイル(index.tpl)を別々のディレクトリに保存できたりします。


- ディレクトリ構成の例

.
|-- doc_root
|   |-- CustomSmarty.class.php
|   `-- index.php
`-- non_doc_root
    `-- tpl_files
        |-- templates
        |   `-- index.tpl 
        |-- templates_c
        |-- cache
        `-- config

アプリごとに異なるテンプレートファイルのディレクトリに保存しておきたい場合は、カスタムクラスをコピーしてbase_dirを書き換えるだけでよいので、1つこういうクラスを用意しておけば開発が楽になるかもしれません。




って議論が社内で起きました。

情報システム部門の担当として、保守やサポートを簡略化することや間違った使用によるトラブル対応のためにも「統一すべきだ」って意見が大半を占めたりしました

もちろん、その立場からの意見であれば、私も同意見です。


ただ、今どきネットで調べればたいていの事が解決するし、数多くあるソフトウェアを統一してこれだけを使えと言うのはナンセンスだろう、というのもあったりします。

私もブラウザはIE限定でとか、開発環境はEclipse使えとか、メーラーはOEしか認めないとか言われたら少しげんなりします。



統一とその弊害


ネット上でも、IE氏ねって言葉が飛び交ってるようにブラウザ一つとっても挙動の違うソフトウェアを社員が使い、それら全てを情報システム部門でサポートしていくなんてとてもじゃないけど無理なわけですよね。

なので、ある程度の範囲のソフトウェアに対象を絞って、これだったらトラブルがあってもサポートするけど、後は知らないから自己責任で使ってね、みたいなスタンスとってたりもします。


ただ、これだけ情報があふれている世の中ですし、便利なものが続々と開発されていく中で、それら全てを押さえ込んでいくのは難しかったりもします。

システム上のポリシーで縛ることも可能ですが、次に「これが便利だから使わせろ」とか言う人も出てくるわけです。

じゃあ、自己責任でお願いしますねって言っても最終的にトラブルがあったときは、情報システム部門に飛び込んできたりもし、「自分が悪いのはわかるがとりあえずこのPCには大事なデータが入っているからなんとか起動して取り出してくれ」みたないことになったりするわけです。


そういう意味で、サポートの対象ソフトウェアを絞ってしまい、トラブルが発生しても対応しやすく、またナレッジを溜めやすい体制にしておいた方が都合がよかったりもします。

そのソフトウェアの保守サポートが受けられるものであれば、なお更その効果も大きくなるでしょう。


一方でIT担当のシステム部門として、一部のソフトウェアしか知らないと言う状況は如何なものか、という考えもあったりします。

ブラウザはIEしか認めません、とした状況で「え?Opera?それ美味しいの?」みたいな状況もまずいだろうと。

高度化する情報技術の中で、その中核を担わなければならないエンジニアがごく限られたソフトウェアしか知らず、最新とはいかなくても技術動向に目を光らせることも無い状況では、育つ人も育たないわけですよね。


ソフトウェアの統一と言うのは、そうした特定の分野しかしらないという技術の偏りや、他のソフトウェアはどうなっているのかという情報収集能力や、それぞれ挙動やトラブルの質が異なるものへの対応能力などを奪ってしまうのではないかな、という考えも持ったりします。



制限することじゃ生み出せないこと


ITリテラシの高い人から見れば、こういったことは個々が知識を高めて自己解決する能力を身に付けていくべきなんじゃないか、みたいな意見が出てきたりもするんですが会社で働く人のその能力はピンきりだったりします。

この個人がと言うところが結構曲者で、入社して簡単な研修を受けることにより、最低限のITリテラシや業務で使うソフトウェアの基本動作は理解をすることもできるかもしれませんが、それ以上のことは自分で調べて知識を付けていくしかないような状況だったりします。


エンジニアだったら、それが仕事だからと言うところもあるのである程度のソフトウェアに触れる機会があったり、様々なところから情報を集めて実際に自分で試してみる、と言うところまで行き着けるかもしれません。

しかし、ITに疎い年配者や普段の業務で最低限のソフトウェアしか触れないような人にとって見れば、何が良いのか/悪いのか、どうやってインストール/設定すればよいのか、どこに行けばそんな情報が落ちているのかさえわからなかったりもします。


このわからない状況によりトラブルを引き起こしたりもするわけですから、それらの人に対してもう少し高いレベルのITリテラシの教育をし、レベルを引き上げることによってトラブル防止や自己解決能力、利用上のトラブルやモラルの向上、情報システム部門に頼らなくてもその周りがサポートできるような体制を取ることが出来れば、サポート業務の負担やリスク軽減にもなるのではないかと思ったりもするわけです。

もちろんこれには制限をかける以上に労力のいることになるかもしれません。

しかし、システムによる制限をするのは簡単ですがそれによって生み出されるものは少なく、ITリテラシを向上させることによって生み出せる効果の方が大きいのではないかなと。

制限をかけることで不満が大きくなったり、窮屈な環境で大きな仕事をするということも難しい状況に追い込むのではないかなと思うわけです。




システムはなぜダウンするのか 知っておきたいシステム障害、信頼性の基礎知識/大和田 尚孝
¥2,520
Amazon.co.jp

この本では、システムダウンの原因を実際のシステムダウンの事例を含め、その原因の体系的にまとめ上げています。

各章ごとに、システムテストや負荷テストへの対策や不具合の事例、OSやアプリケーション、ハードウェアレイヤでの障害や一般的な対策、運用オペレータによる入力ミスなどによる障害の発生事例などが描かれています。


ただ、障害対策へ技術的な観点からのどのような構成をとるべきとか、どのような対策ツールがあるのかなどについて、深い視点では切り込んでいないので、そういった技術的観点を希望するなら、「[24時間365日] サーバ/インフラを支える技術 」の方がよいかもしれません。


新人エンジニアにはシステム運用と障害対策のいろはを、中堅エンジニアにはシステム障害対策に対する幅広い知識を、プロジェクトマネージャにはシステム構築・運用の網羅的なリスク管理への対策、として有効になるのではないでしょうか。

エンジニアではなくとも、IT担当としてシステムの維持・管理をしなくてはならない立場であれば、ここに書かれているような知識や事例と言うのは一度目を通しておいた方がよいと感じます。


ある程度システム開発や運用の現場で経験をつんだエンジニアであれば、ここに書かれた障害事例などは自分の経験と照らし合わせても、思い当たる節が出てくるのではないかと思います。

私も読んでいて、実際にそうなったら笑い事ではありませんけど、これはあの時のあのトラブルに当てはまるな、って当時の思い出と重なったりしました。

そして、システムトラブルと言うものは、自分の現場特有のものではなく、どこのシステム運用者も似たようなトラブルで悩まされており、その対策と日々格闘しているのだなとも。


こういった失敗の事例という物からの方が学べることが多いので、そのシステムトラブルの原因を体系的にまとめ上げているのは、貴重な情報源になるのではないでしょうか。



システムはなぜダウンするのか 目次


第1章 システムが止まった・・・
1.1 停止 = ダウンは誤解
1.2 ダウンは原因から4種類に分けられる

第2章 きちんとテストしたはずなのに・・・
2.1 突然に目を覚ます20世紀のバグ
2.2 忘れたころにやってくる「日付問題」
2.3 データベースのデッドロックが連発

第3章 アプリケーションだけではない・・・
3.1 停止を検地できない
3.2 組み合わせを変えたら動かない
3.3 メモリーをつかんだまま解放しない

第4章 アクセス殺到に耐え切れず・・・
4.1 ハードウェアの性能を活かしきれない
4.2 メモリー、CPUが足りない
4.3 通信データの増加がダウンをまねく
4.4 データベースが満杯に
4.5 夜が明けてもバッチ処理が終らない

第5章 気付かなかったは許されない・・・
5.1 つい見逃すパラメータ変更
5.2 システム環境の変更ミス
5.3 バッチ・ファイルの適用忘れ
5.4 カレンダーの設定ミス

第6章 その「うっかり」が致命傷・・・
6.1 運用コマンドを間違える
6.2 データの移行・入力ミス
6.3 待機系への切り替えに失敗
6.4 混乱が「2次災害」を生み被害拡大

第7章 まさか、こんなことが起こるとは・・・
7.1 サーバーが壊れた
7.2 通信ネットワークが不通に
7.3 コンピュータ、電気なければただの箱
7.4 震災でデータセンターが破壊・焼失

第8章 障害対応は時間との闘い・・・
8.1 原因究明よりも復旧を優先