つれずれなるままの開発日記(最近はFlexばかり..)

Archive for 1月, 2010

最近、The GOALを読んでからちょっとだけ、TOCを勉強してみようかなと思いかじっているうちに、ITプロジェクトの管理に関しては本格的に勉強する価値があるのではないか？という気がしてきた。つまり、自分で経験的に知っているというレベルから、人に説明するうえで体系的な知識として使えるのでは？という意味です。

（The GOALを知りたい方はこちらもどうぞ。）

現場でITプロジェクト管理をやっていると、まず、政治的関係者は、PMBOKなどの言葉や、また、工学的な理論などよりも、マーケティングやら販売手法やらを考えている人たちの言葉に近いほうを形式的に学んだほうがいいような気がする。

というのも、PMBOKなどをかじる機会があったが、あまりに規模がでかすぎるという気がした。
何々、何々をするべき・・・
ってあるが、ITプロジェクトでは数百万から2,3千万程度の案件では、実際の実働部隊は二人くらいで、それ以外すべて管理者なんてことだってあり得る。ほとんどは、管理者の管理に翻弄され、実動する人たちに何も伝えられないって場合があるのではないだろうか？
で、実際には、実動する二人が勝手につくってしまってある程度できてから、やっとまともな話ができる状態になる。

そんなのが普通というときに、だいそれた「PMBOK」やら高度情報処理試験での「プロジェクトマネージャ」の理屈・知識は本当に通用するのだろうか？
あまりに、正論すぎる気がする。
（知らないより、知っていたほうがいいのはよくわかるし、それに、よく理解していれば使えるのもよくわかる。でも、小さい（予算が少ない）案件ほど、かなりの変則的応用を求められると思うので、小さい案件で基本を学び、徐々におおきくってプロジェクト管理の手法の学習としては無理があるのではないだろうか？関係者の調整力を学んでいくっては有効だが・・・
それに、学問が正論じゃなきゃ意味がないだろ！っていう気もする。）

それよりも、ほとんどうまくいかなく、問題と間違いだらけという前提から始めることができる「制約理論」ってのは、かなり現実にフィットしている気がする。
たとえば、「スケジュールというのを意思として決める」というより、制約として上から落ちてくるってのが普通だと思うし、使う技術・環境なんかも、選択するっていうよりも、今いるメンバーやハードで何が、どこまでできるか？っていう制約って考えるということになる。
たとえば、何かを変更したときに、カッコよく言えば「変更管理」っていうが、要は間違いに気付いただけだったりする。しかし、それを知る手法がわからないとか・・・

それに、たいてい失敗しているプロジェクトをみると、崇高な感じのドキュメントやら、過剰に投資した環境が多々見られる。なんでこんなになってるんだー。ってみると、コンサルタントなどを通して形式的には正しい方法をとっていたり・・・

という意味では、こんな時代に必要なのは、「失敗しないためのプロジェクト管理」ではなく、失敗の中から「成功させる」を生み出す理論のほうが大切なのではないだろうか？

そう考えれば、人は自由な選択と意思から計画的に生み出すものよりも、多々ある制約から生み出すものの方がよりいいものが生まれると思ってしまうのは私だけだろうか？

私も過去、自分がある制約からやりたいことができず、んー「まあ、これで今のところはいいか！？時間があるときにきちんと作りなおそう」と言って割り切って機能を実装したものが、ほかの会社ではその機能をみて、どうやってそれを実装しようかと試行錯誤していたということを聞いた。
それは、まさに制約から偶然生まれた「そういう事」だったのかも知れない。

次回は、「制約理論」と「サーバ管理」の関係を書いてみたと思う。

以前公開していた、ZIP圧縮・解凍ライブラリですが、airxmailと同様にGoogle Codeに移動して公開することにしました。
こちらです。

これに伴い、ライブラリ名をairxzipに変更し、パッケージ名も変更しました。

まだまだ準備不足ですが・・・・

また、これ以外にパスワード付きZIPファイルにも一部対応しました。
ただし、ZipCrypto（PKWare crypto)形式の暗号化のみです。
こちらで説明されている、VII. Traditional PKWARE Encryptio　という形式のみです。

この形式はWindowsXPなどで使われている暗号形式ですので、まあ、ふつうの人が一般的に目にするレベルでは使えるようになったと思います。

パスワード付きZIPファイルの使い方は以下のようになります。

作成(圧縮)方法

[AS]
var writer:ZipFileWriter = new ZipFileWriter();
// パスワードの指定
// パスワードの指定がなければ、通常のZIPファイルが作成されます。
writer.setPassword(“pass”);
writer.open(File.desktopDirectory.resolvePath(“crypto_airxzip.zip”));

// Add ByteArrayとして追加する場合
// ファイル名は”sample.txt”とする。
var data:ByteArray = new ByteArray();
data.writeUTFBytes(“SAMPLE”);
writer.addBytes(data,”sample.txt”);

// Add Directory
// 空のディレクトリを追加する
writer.addDirectory(“Foo1″);

// ローカルにあるファイルを指定する場合
writer.addFile(File.desktopDirectory.resolvePath(“image.jpg”),”Foo1/image.jpg”);

// close()を忘れずに！！
writer.close();
[/AS]

解凍方法

[AS]
var reader:ZipFileReader = new ZipFileReader();
var file:File = File.desktopDirectory.resolvePath(“crypto_airxzip.zip”);
reader.open(file);
reader.setPassword(“pass”);
var list:Array = reader.getEntries();

for each(var entry:ZipEntry in list){
if(!entry.isDirectory()){
if(entry.getFilename() == “sample.txt”){
try{
var bytes:ByteArray = reader.unzip(entry);
log.debug(“sample.txt : ” + bytes);
}
catch(e:ZipError){
log.warn(entry.getFilename() + “:” + e.message);
}
}
}
}
[/AS]

最近ノートパソコンを使って作業をすることも多くなり、
自宅にあるデータを外出先からみたいという気持も多々あり、
また、複数あるＰＣで共有するデータをNASのようなところにおいておきたい。
ダウンロードしたフリーのソフトなどは、たびたびダウンロードするようなこともしたくないし、
なにより、また、探すのが面倒だ。

でも、「新たな機器を増やしたくないなー」と思っていたので、仕方がなくUSBメモリで共有していた。

そこへ、部屋の模様替えに伴い、ブロードバンドルータから線がながーくでてしまうことになり、
また、Wiiとかにも接続したいしと・・・いろいろ調べるよりも新しくしてしまう方が楽かなということで、
思い切って数年ぶりに買い替えることにした。

予算は１万円程度。

さらに、上の用途を満たすために、
「VPN機能（外出先から自宅へのアクセス）」
「NAS機能（ネットワークストレージ機能）」
をみたしているものにした。

いやー、ほんの数年前までこんなことは簡単に、かつ安価にできなかった気がするが、進歩は早いものです。

そして、実際に買ったのはこれです。

BICで9800円のポイント20%付きで買いました。
そして、後で、このポイントを使って8GのUSBメモリを買いました。

さらにこのルータはWOL(Wake On LAN)というLANを通してPCに電源を入れることもできます。
したがって、必要になったら電源を入れるということもできるのです。

このあたりもルータですべてできてしまうのはいいですね。
家庭的にはルータに常に電源がはいっているのは許せますが、
多少なりともＰＣなどうるさい機器が使わないときに電気が入っているのは嫌ですから・・・・

ただし、IPが動的の場合、DynamicDNSのサービスを使わないと実質的にはできないのでご注意を。

AIRで動くことを前提にライブラリを作成していていると、
AIRのラインタイムバージョンが気になることがある。

このきっかけは、flash.net.Socketのtimeoutプロパティを設定しようとしたが、
Flex Builderではきちんとコードヘルプとしてtimeoutプロパティが表示されるのだが、
いざ、実行しようとするとtimeoutプロパティがないとエラーになる。

「なぜ！」と思ってしまったが、PCを引っ越したためにFlex Builderを新規に入れなおしたが、
ここで、Flex BuilderでのAIRが1.5でなくなってしまった。

このSocketのtimeoutはAIR1.5から使えるのだ。

原因がわかった時点で問題となるソースを修正することはできたが、
そもそも、AIRのバージョンってどうやってとるんだ？

という疑問が生じたので調べてみた。

[AS]
WindowedApplication.nativeApplication.runtimeVersion
[/AS]
で取得できる。
マニュアルはこちら

ちなみに出力結果はこんな感じになる。

1.5.0.7220

今回は、前回で簡単なテキストメールを送るところまで説明しましたが、
マルチパート（HTML)メールを送ります。

単純なテキストメールを送るだけなら、それほどライブラリなど使わずに単純にがりがりと書いてしまった方が楽ではありますが、
マルチパートとなると、Boundaryなどが出てきてそれなりに面倒ですので、やっと、ライブラリを使った方がいいかなという感じが出てきます。

ただし、前回からライブラリが新しくなったので、こちらからもっとも新しいバージョンをダウンロードしてください。

さて、マルチパートの作成ですが、

var contentType:ContentType = ContentType.MULTIPART_ALTERNATIVE;
var mimeMsg:MimeMessage = new MimeMessage(contentType);

var from:INetAddress = new INetAddress();
from.personal = "Sample User";
from.address = this.fromEmail;

mimeMsg.setFrom(from);
var toAddr:INetAddress = new INetAddress(this.toEmail,"Customer");
mimeMsg.addRcpt(RecipientType.TO,toAddr);
// set mail subject
mimeMsg.setSubject("これは日本語メールです");
mimeMsg.setTextBody("this is multipart message");

// TextPart
var partText:MimeTextPart = mimeMsg.createTextPart();
partText.setText("これは通常の本文");

// HtmlPart
var partHtml:MimeTextPart = mimeMsg.createTextPart();
partHtml.setHtmlText("<html><body><b>ここにはHTMLの本文</b></body></html>");

sender.send(mimeMsg);
sender.close();

とこんな感じです。
ここで前回とちがって注意すべきところが３点ほどあります。

マルチパートであることを伝える

var contentType:ContentType = ContentType.MULTIPART_ALTERNATIVE;
var mimeMsg:MimeMessage = new MimeMessage(contentType);

前回までは、コンストラクタに引数がなかったのですが、引数がない場合には、text/plainに自動的になってしまいます。
従って、ここでは、multipart/alternativeのパートを作成します。

子供のパートを作成する

var partText:MimeTextPart = mimeMsg.createTextPart();

これで、子供のパート（text/xxxxx）として追加します。

テキストもしくはHTMLを本文に設定する。

MimeTextPartには、

• setText
• setHtmlText

の２つの本文設定メソッドがあります。
つまり、setTextを使ったときには、text/plain
setHtmlTextを使ったときには text/html　となるわけです。

次回は、添付ファイルをつけたメールの送信を説明したいと思います。

本の紹介:「ザ・ゴール１・２（企業の究極の目的とは何か・思考プロセス）」

年末年始に、上記本を読んでみました。といっても、３日ぐらいでこたつにはいって読み切りました。

まあ、年末年始くらいはあまり読みそうにない本をあえて選んでみることにし、
以前、本屋でたくさんならんでいたのを思い出し、これらの本を読んでみることにしました。

ストーリーとか、内容とかは他のサイトでも、Amazonでの批評などでもわかると思いますので、
ここは、あるいちIT技術者として読んだ時の感想とでも述べたいと思います。

まず、１のほうの内容（理論）はまあ、考え方が体系化されて説明されてはいますが、
普段、このような思考をめぐらせて仕事をやっているので、それほど新鮮味は感じませんでした。
それと、舞台が製造業なのでちょっと、違和感があるといえなくもありません。
しかし、１の話がわからないと２の話につながらないので、さらっと読んだほうがいいというレベルでした。

２では、製造プロセスの改善というストーリーから、思考プロセスの改善という方向へすすんでいきます。
したがって、より広い範囲で適用可能ということで、内容も具体的なことから抽象的な話へすすんでいきます。

この２も技術者として読んでいくとそれほど新鮮味もないのですが、
これが「マネジメント」「マーケティング」という分野に向けても書かれている内容なのです。

しかも、これがそれらの分野の人たちには「新鮮」というじゃありませんか！
もちろん、理論自体が新しいということではなく、現在の人がその発想を知るということが新鮮という意味です。
ですから、本屋さんの目立つ棚にあったわけです。

でも、先ほど言ったように、考え方（思考の癖とプロセス）はもともと、
科学者などがやってきたアプローチをもとにしているのですから、
それは、技術者である私がなじみやすいと思ったのもうなずけると思います。

その証拠に、たとえば「アルゴリズムを作るための思考プロセス」、「システムのボトルネックを見つける思考プロセス」
なんてような本が技術書の棚で目立つようなところにあることはないと思います。
「プロセス」自体の説明はありますが、プロセスを作るためのプロセスまで説明はたいていしません。

したがって、技術者たちはこのような思考プロセスをすでにもっていることを前提に、
ほとんどの本が記述されているだとおもいます。

ようは、私がこれらの本をよんでちょっと新鮮に思ったのは、

１．「マネジメント」「マーケティング」に関しての思考プロセスはすでに技術者のほうが理解できている。
２．コンサルタントや経営者・管理者などと、「思考プロセス」がことなるからわかりあえないなんてことはない。

ということです。
でも、実際、管理職や経営者から理論的思考に基づいた話を聞くのはまれなのです・・・・
（だから、コンサルタントからこのような理論をまとめてもらう必要がでているのでしょうが・・・）

これは、「思考プロセス（という文字）」が「理系」だからではないでしょうか？
なぜか、日本人（以外はしりませんが・・・）は、事を「理系」か「文系」かに分ける人が多くいます。
そして、このように分ける人は、「理系」と「文系」はお互い侵食しあわないようにしている風潮があります。

したがって、「文系」と自負する人間はこの「理系」な異物を拒否するのではないでしょうか？
同様に自分が「理系」と自負する人間も「マーケティング・経営（政治）」とかの「文系」な異物を拒否するのでしょう。

このような考え方を持っている方が広く人の上にたってもらうには、
中高時の「理系」「文系」という人の２極化による分離をやめれるようにすればいいのかなと思いました。

私も高校なんかの時には、「文系」と言われることはまったく勉強しなくてもいいとおもったほどですし・・・

ようは大学入試至上主義から来ているのかなーと思った次第です。

せめて、「文学系」、「芸術系」、「工学系」、「理学系」・・・なんて別れていて、
２つぐらい選ぶようになっていれば、もうちょっとましになったかなーなんて、思ったお正月でした。

前回、メールの送受信するAIRのライブラリ公開(airxmail)をお知らせしたが、
今回は、オーソドックスなメールの送信方法を紹介します。

その前に、必要なライブラリをサイトからダウンロードしてください。
ダウンロードタブから、coltware_airxmail_r15.swcをダウンロードしてください。

airxmailのサイト

このサンプルで必要なクラス

import com.coltware.airxmail.MailSender.SMTPSender;
import com.coltware.airxmail.MimeMessage;
import com.coltware.airxmail.INetAddress;
import com.coltware.airxmail.RecipientType;

SMTPSenderクラスは、SMTPのプロトコルを使ってメールを送信するためのクラスです。
実際のSMTPのプロトコルベースでメールを送信しなくてもいいようにしてあります。

SMTPのプロトコルを意識してプログラムする場合には、SMTPClientというクラスを使う必要があります。

さて、このクラスの大まかな流れですが・・・

var sender:SMTPSender = new SMTPSender();
//  ここで必要な環境設定を行う
sender.setParameter([KEY],[VALUE]);

var msg:MimeMessage = new MimeMessage();
//  メッセージオブジェクトの作成

sender.send(msg);
sender.close();

のような感じでメールが送れるようにしております。
非常に簡単な感じになっていると思います。

では、setParameterで指定する値ですが、基本的には

• サーバ名:SMTPSender.HOST(文字列型)

だけでもいいのですが、認証(SMTP AUTH)を使っている場合や、gmailなど25番ポート以外場合を使う場合が考えられます。
この場合には、以下のパラメータも指定してください。

• ポート番号:SMTPSender.PORT(数値型)
• 認証を使う指定:SMTPSender.AUTH(Boolean型)
• ユーザ名:SMTPSender.USERNAME(文字列型)
• パスワード:SMTPSender.PASSWORD(文字列型)
• SSL/TLSを使う指定:SMTPSender.SSL(Boolean型）

ただし、SSL/TLSを使う場合には、内部で作成されるオブジェクトが自動的にas3cryptoのオブジェクトが使われますので、
依存するこのライブラリを自前で用意してください。

また、認証はサーバから要求された場合のみ認証するようにしております、もし、うまく認証が動いていないようであれば、
このあたりの処理を疑うといいかもしれません。

では、次にメール本文を作成する処理ですが、

var mimeMsg:MimeMessage = new MimeMessage();

var from:INetAddress = new INetAddress();
from.personal = "送信者";
from.address = this.fromEmail;

mimeMsg.setFrom(from);
var toAddr:INetAddress = new INetAddress(this.toEmail,"受信者");
mimeMsg.addRcpt(RecipientType.TO,toAddr);
// サブジェクトを指定する
mimeMsg.setSubject("初めてのメール");
mimeMsg.setTextBody("これは本文です。\r\n２行目です");

sender.send(mimeMsg);
sender.close();

のようにすればOKです。
ここでは、単純なtextメールのサンプルですが、添付ファイル付のメールなども送れます。

もうちょっと、応用した使い方は今後紹介していきます。

今まで、AIRを使ってSMTPとPOP3でメールを送受信するライブラリを作ってきたので、
それをgoogle codeに公開して開発するようにしました。
google code自体もなれていないので、これでいいのかすらまだよくわかっていませんが・・・・
こちらでーす。
http://airxmail.googlecode.com

まだまだ、ドキュメントなどがそろってはいませんが、こちらのブログでも随時紹介していきたいと思います。

SMTPやPOP3のプロトコルを詳しく知らなくても、メールの送受信ができるようにしました。

実装するにあたりJava Mailをある程度は参考にしましたが、めんどくさくなってしまった部分もあります。
というより、リリースがだいぶ遅くなりましたが、これが初めてのAS3プログラミングだったために、
命名規則やら、実装方法やら、だいぶ自分の中でもぶれてしまい、これをあわせるのが面倒になってしまった。

ただ、MIME形式を意識してプログラミングするよりかは、はるかに楽になっていると思います。

IMAPは将来的には実装するつもりはありますが、当分予定はありません。

自分の環境では、niftyとgmail、ローカルではSMTPはpostfix(AUTHなし）、pop3はdovecodを使って確認しています。
ただし、gmailなど、TLSを使って通信する必要がある場合には、別途、as3cryptoのライブラリが必要になります。

このあたり、AIRv2ならばSocketでTLSが使えるようなので、時間があるときにでも確認してみます。

ちょっと、国内でクラウドを扱うところとおはなしができた。
しかし、まだまだ、レンタルサーバ、VPS(Vertual Private Server)のレベルを抜け切れていない気がする。
せっかく、クラウドという新しい名前を導入するのだから、新たな考えを持ち出さなければ、単なる「バズワード」として終わってしまう可能性もある。
（これではますます、日本はITから遠のいてしまう。）

そもそも、クラウドに望むことは何であろうか？
しかも、今の時点で。ということだ。

やはり、いえることは「サーバの数を減らしたい」ということだが、
これは果たして、現時点という段階という条件を付け加えても、クラウドを導入するための「GOAL」といえるだろうか。
（ちょっと、お正月休みを使って、The GOAL とThe GOAL2を読んでみました。後でこのあたりも書きたいな。）

私の経験では、ほとんどの会社が「サーバの数を減らしたい」という要望に関しては、クラウドなどを用いずとも減らせる。と思う。
単に、上からある程度のルールは変えていいから、20%減らせといえば、問題なく減らせる。

最近は、CPUも2COREだのが当たり前だしメモリだって安い、そもそも、サーバは供給過剰状態になって運用されているのだ。

リソースを調べてみれば、ほとんどが使われていない状態であることに気がつくだろう。
多くの会社がSIやさんにおだてられ、やれストレージだ、IDSだ、ロードバランサーだ、とダンプカーなみに重量になってしまい、
今や、それを運転することもままならない状態になっているのだと思う。
おかげで、ちょっとハンドル操作を間違えれば大惨事ってことさえかんがえられる。
そして、個人情報保護を守るためといい、そのサーバの役割を超えて、共有させてはいけないなど・・・

「サーバの台数は増えるは、ネットワークは複雑になるは」そして、極めつけは、システムのリプレースという重量オーバーの荷物が荷台にのっかってしまった。

そう、単純に「安全に正しく運用する」というポリシーを作るときに、あーだ、こーだと言ってくるやから（利害関係を作る要素）が多すぎるのだ。
関係者が多くなれば、それを満たすルールが複雑になる。そうすると、穴ができやすくなる。従って、それをつぶすために、さらに複雑なルールに。

システムを運用するためにいいことは「安全にシンプルに運用する」ということなのだが、「安全・安心」部分のプレッシャが強調され、関係者たちは「安全」かどうかわからないほど複雑にすることで、それが安全でないともいえない。という方法を選んだ。
また、同時にこの手法は、SIerたちのいい売り上げになったし、なにより、なぜか、システムの利用者たちは「システムのそれ自体で完結して安全である」という解を望む人が多いので、「ここはこれで大丈夫なの」と聞けば、SIやさんは喜んで、サーバを追加して、解をだしてきた。
利用者たちも、自ら複雑にすることを進んで行うように意図せずしてしまっていたのだ。

そして、多くの会社が、ここがダウンしたらシステムはどういう手順で復旧するんですか？という問いには答えられなくなり、２重化しているから自動的にとかという一見大丈夫そうに聞こえるが、細かく聞けば何もわかっていないという状態になっている。

だが、ここ最近の不況のせいもあり、「安全」をより「安く」がどの業界でも強く求められ、何らかの変化を求められている。
そこで、「クラウド」という良薬があるらしいということである。

しかし、まだ実体はまだついてきていない。
システム構成が物理的なものに縛られていた時代の構成をたんに、VMとして安く、実施できますなんていう「クラウド」は、
利用者にとって、物理的なハードの値下げと同じような感覚しかないように思う。
でも、ハードを数年前に買ったものに比べれば断然よくなってきているので、今と同じスペックでよければハードも安い。
これでは、たとえばハード代は年間100万円安くなります。ただし、運用費は若干増えます。

といわれても、果たして数人が数ヶ月つかって移行しなければならないほどの魅力があるだろうか？

さて、ここまでくると、もうちょっと「クラウド」を使う目的が見えてきた。
「サーバの数が増えてしまった」原因をなくしたいのだ。

１．運用ポリシーの見直し単純にする
　関係者の分だけ、サーバ（ネットワーク）が存在することをやめたい。
２．安全・安心の向上
　ソフトは壊れないが、ハードは壊れるという事実のプレッシャーから解放されたい。
（実際にはソフトも正しく設定していないので、壊れる（動かなくなる）ということの方がよく起きるんですが、それはシステム屋しかしらないことであり、関心ごとにはならないし、そもそも、実はその障害がでるほどビジネスが成功していないという事実もある。）
３．コストの削減
　何より、経営陣の興味はこれ。これができれば、大義名分は取り付ける。

これらが実現できるなら、むしろ、サーバ（クラウドの場合にはVMだが）は部分的に増えてもいい。
クラウドを提供する側は、１，２を満たすようにこれまでの自由度を奪い、シンプル＆安全を満たすような制限をむしろ設ける方にいかなければならない。

「自由じゃありません。考えも変えてください。でも、その代わり、安心をより安く提供できます。」と。

だからといって、現在のGoogle App Engineのようなクラウドは通常の会社にとっては行き過ぎだ。
ダンプカーから、町乗り用の軽に乗り換えたいだけなのに、それを通り越してレーシングカー（ただし安い）にまでさせられるような気分だ。
（プログラマーとしてはもちろん乗ってみたいのは、レーシングカーだ。安くてエキサイティングならこりゃいい。）

初めて、クラウドというものをまじめにみてみると、確かにいわれているように現時点で「Amazon」のサービスがもっともバランスがもっともとれているように感じる。
ただし、日本で運用するサービスとなると法律面なども含めて課題が多い。
（これは、もっとも関係したくないポリシーだ。）

しかしながら、それを乗り越え、クラウドで１から３まで実現できたとなると、同時に必要な人の数も減らすことができるだろう。

さて、これは不景気で明日の先行きがわからないという状況で、進んで行うようなことができる企業がどれだけあるだろうか？
（つまり、実践できた部署は、その部署がいらなくなるということもあり得るという意味。）

となれば、これをきちんと行えるには、「新しい分野への挑戦」という投資があることも同時に必要になってくるのではないだろうか？
でも、コスト削減を掲げつつ、新しいコスト増加！？
んー、考えれば考えるほど、「強さはより強さを得るこができ、弱さはより弱さを招く」という結論になってしまった。

一見すごく簡単そうなのに、ちょっとはまってしまったので記録。

システムがなんか変な時に、topコマンドをまず見てみる。
でも、遅い時がわかっているが、自分がその時にtopコマンドを実行できないなどという場合には、
topコマンドをバッチモードでしかも、cronで定期的に動かせばいい。

マニュアルを

http://www.linux.or.jp/JM/html/procps/man1/top.1.html

見ればわかるが、覚書のために自分が使う手順を載せておく。

top -n 1 -b

これで１回限り、TOPコマンドの結果が出力される。
したがって、これをcronで起動させればいいので、

*/10 * * * * top -n 3 -b > /tmp/top_`date +%H%M.txt`

のようにしておけば、１０分毎に3回のTOPコマンドの結果を/tmpの下に保存しておける。
ちなみに、

`date +%H%M`

としているのは、あまり日ごとの結果を取っておいてもしかたがないとおもったので、
毎日同じファイルに上書きするためです。

ところが、あれ！？
書き出されない。
/var/log/message
をみると

top -n 3 -b > /tmp/top_`date +

ってなぜか、+以降表示されていない。

http://www.linux.or.jp/JM/html/cron/man5/crontab.5.html

をみると、”%”に特別な意味があるらしい。
“+”から特別な意味があるらしいとよんでしまってしまったので、ちょっとはまった。

次に、きちんとファイルはできたが中身がない。。。
しょうがないので、標準エラーを標準入力に出力されるようにしたら・・・・
TERMの変数がないとのこと。

結局、きちんと動くようにしたものは

*/10 * * * * export TERM=vt100;top -n 1 -b > /tmp/top.`date +\%H\%M`.txt 2>&1

これです。

結果でから問題が毎回見つかるようなプロセスがあれば、
さらに、プロセスIDから/proc/[プロセスID]の下を見ていけばもっと詳細な情報がわかる。

まあ、ここから先は実際に問題がtopコマンドで見れたら書いていくと思います。