« November 2006 | Main | January 2007 »

December 31, 2006

給与だけを考えた場合の賢い会社の選び方

いまさら聞けない、「XML」の基礎

個人的には給与だけで会社を決めるという考え方は好きではありませんが、とはいえ給与が生活の基本なのでこれを重視される方も多いでしょう。そこで今回は、冷静に考えれば当たり前のことを記してみたいと思います。

【儲かっていない会社は高い給与が払えない】
当たり前ですが、儲かっていない会社は給与の元となる原資がないので高い給与が払えないです。非常に大雑把な計算式をお教えしましょう。それは会社概要の年間売上高を従業員数で割ってみるというものです。

例:
 A) 年間売上高 1兆円 / 従業員数 5万人 = 2000万円
 B) 年間売上高 10億円 / 従業員数 50人 = 1000万円
 C) 年間売上高 1億円 / 従業員数 2人 = 5000万円

※Aは大企業、Bは中小企業、Cは零細企業となりますが、1人あたりの売り上げで見ると、実はCの零細企業がトップだということがわかります。

さて、もし売り上げの中の人件費が占める割合が30%だとすると各企業の給与平均額はそれぞれ600万円、300万円、1500万円となります。1人あたりの売上高が高ければ高いほど高い給与を払える余地が大きくなってきます。無論業種によって利益率や人件費の占める割合は異なるのであくまでも参考値ですが、少なくとも儲かっていない会社はこの計算式で簡単に把握できます。


【求人情報ページはあらゆる情報が満載】
求人情報ページを見ると自分が気になっている会社が載っていることがよくあります。社内の写真だったり、実際に働いている人のコメントだったり。ただし注意すべきは所詮広告ですから、概して良い部分を強調しているという点はしっかり押さえておく必要があります。私が求人情報ページで一番チェックするのは、ごく一部のネガティブ情報です。例えば「締め切り前になると徹夜・残業をする場合もありますが・・・」とか「研修期間を終えると給与がアップします」などです。これを深読みすると、割と徹夜・残業が多い職場なんだなあとか、研修期間がどのくらいかわからないけど例えばそれが5年だったら5年間安月給なんだろうなあとか、そのように捕らえます。すなわち、良い情報は誇張されているけど、悪い情報は意外と実情を示している、という感じです。


【子会社は親会社より給与が安い】
NTTドコモなど例外はありますが、概して子会社は親会社より給与が安いと言えます。この根拠としては、大きな仕事は親会社で、小さな仕事は子会社で、という明確な区別があるからです。売り上げや利益幅が大きい仕事を親会社が取り、そうでない仕事を子会社が取ると考えたら子会社は親会社より給与が安いのが当たり前と言えます。


【まとめ】
というわけで、高い給与をもらいたいのであれば、まずは明らかに給与が安そうな会社(1人あたりの売り上げが小さい、求人情報で深刻なネガティブ情報がある、子会社・孫会社、・・・である)を避けましょう。それから会社に入ったら1人あたりの売上高が上がるように頑張りましょう。これで高い給与がもらえるようになります。

・・・以上、当たり前のことを記してみました。

| | Comments (0) | TrackBack (0)

December 29, 2006

telnetを使ってメールを送信する

自分用のメモがてら記しておきます。

!!!警告!!! もしこれをTipsとして使う場合は、きちんと周辺知識を固めてからにしてください。

【とりあえず送る場合】

% telnet mail.hogehoge.jp 25

MAIL FROM:<sousinsya@hogehoge.jp>
RCPT TO:<jusinsya@hogehoge.jp>
DATA
Subject: test
To: jusinsya@hogehoge.jp
From: sousinsya@hogehoge.jp
test test.
.
QUIT

システム管理者であればこのくらいは暗記しておきたいところです。(といいつつ私はたまに部分的に忘れます・・・)

【一応注意点】

1. 何はなくてもRFCが基本!
2. 不正リレー対策が施されていないサーバで実行すると・・・。
3. 誤ったメール系処理を被害は甚大。他の人に迷惑をかけないよう十分注意しましょう。

| | Comments (2) | TrackBack (0)

December 26, 2006

続:複数WEBサーバへの最新ソースコード配信方法

前回複数WEBサーバへの最新ソースコード配信方法という記事を書きました。前回はやり方だけを記しましたが、実際に試してみるといろいろ注意すべき点がみつかります。そこで今回は続編としてそれらの注意点を記します。

【配信に失敗する場合があるので気をつける】
rsyncやrobocopyが常にうまく動いてくれればいいですが、たまに配信に失敗することがあります。例えば100台に配信しようとして99台だけうまくいって1台だけコケた場合を考えて見ましょう。この場合何も対策を行わないと発見が難しいです。最悪なのはユーザからの指摘で気づくことでしょう。

この対策にはいろいろあります。

 ・方法1:全サーバのコンテンツフォルダ配下のチェックサムを取って比較し同一なことをチェックする。(一番確実)

 ・方法2:rsyncやrobocopyのログを自動もしくは手動でチェックする。(うまくやらないと漏れが生じる可能性がある)

 ・方法3:version.htmlのようなファイルを作り配信日を入れてそれも配信する。配信後全サーバのversion.htmlの内容をチェックする。(実装は結構簡単)

 ・方法4:rsyncやrobocopyを3~5回繰り返す。(確実ではないけど大抵の場合うまく配信される。が、本質的な解決にはならない)


【HDD空き容量に気をつける】
配信に失敗する原因で一番多いのはHDD空き容量不足です。特定サーバだけ何故か巨大なログファイルが残っていてHDD容量不足で配信に失敗することが意外とよくあります。サーバリソース監視システムが導入されているのであれば発見が容易ですが、そうでないのであれば注意する必要があります。


【それ以外】
それ以外だと「ネットワーク障害」と「認証失敗」がまれに起こります。ネットワーク障害は、例えばLANケーブルが抜けかかっていただとかL2スイッチの特定ポートだけが故障したなどがあります。認証失敗は、例えばサーバの全パスワードを変更したつもりが1台だけ漏れていたなどがあります。


単純な作業の中にもいろいろノウハウがあります。なかなか奥が深いですね。

| | Comments (2) | TrackBack (0)

December 22, 2006

複数WEBサーバへの最新ソースコード配信方法

WEBサーバを数台用意して負荷分散している会社が多いと思います。このような場合必ず悩むのが、どうやって複数WEBサーバへ最新ソースコードを配信するかだと思います。そこで今回はソースコードを複数サーバにコピーする方法について述べてみたいと思います。

【その前にネットワーク確認】
まずはネットワークを確認したいと思います。ほとんどの会社は図1のような感じだと思いますが、安全性を考えればできれば図2のレベルまで持って行きたいところです。

Staging1
図1

Staging2
図2

【ステージングサーバを用意しよう】
次に押さえたいのがステージングサーバです。小さな会社ではWEB1にまずは最新ソースを置いて、そこから他のサーバにコピーする方法を取っているかもしれません。しかしいろいろな意味で配信専用のステージングサーバを別途用意することをお勧めします。ステージングサーバを用意することのメリットは

 1.ステージングサーバもWEBサーバと同じ設定をしておけば上で配信前の最後の最後にテストができる。
   →PCのhostsファイルに、サービス用FQDNをステージングサーバのIPで書くなどの方法でテスト可能。

 2.本番サーバとステージング用サーバで別々の権限設定ができる。
   →本番サーバにはシステム管理者しかアクセスできないが、ステージングは開発責任者以上とか。

 3.その他企業秘密で書けないけどやってみないとわからないメリットたくさん。

※ただしあまりに便利なステージングサーバ。死亡すると結構業務に支障が出るのでハードウェアはいいもの使ったほうがよいと思います。

【ソースコードを配信するためのコマンド】
興味があっていろいろな人に聞いてみましたが、UNIX/Linux系だとrsync、Windows系だとrobocopy.exeがとてもよく使われるようです(私も基本的にはそうです)。

rsyncはSSHを使った配信もできる反面、暗号化しながら送るので配信にとても時間がかかるというデメリットもあります。rsyncを使ったサンプルは以下のような感じです。


rsync -aurz -e ssh /var/www 192.168.0.101:/var/www

robocopy.exeはWindows2000のリソースキットに付いています。Windows2003のリソースキットに付いているかは知りませんが、Windows2000のrobocopy.exeがWindows2003で動くことは確認しています。robocopy.exeを使ったサンプルは以下のような感じです。まあシンプルですよね。


@echo off
REM robocopy /E /XO G:\ F:\

SET SRC_PATH=D:\www\src

CD D:\www\src

ECHO WEB1
D:\bin\robocopy.exe /E /XO /W:3 %SRC_PATH% \\192.168.0.101\src >> d:\Logs\logfile_WEB1.txt

ECHO WEB2
D:\bin\robocopy.exe /E /XO /W:3 %SRC_PATH% \\192.168.0.102\src >> d:\Logs\logfile_WEB2.txt

ECHO WEB3
D:\bin\robocopy.exe /E /XO /W:3 %SRC_PATH% \\192.168.0.103\src >> d:\Logs\logfile_WEB3.txt



双方のコマンドを利用するときの注意としては、「送信元にはあって送信先にないファイルを全て削除する」というオプションを付けると、配信時にコマンド入力を間違えると送信先のファイルが全部消えてしまうことがあります。この事故はとてもよく起こるので注意しましょう。



| | Comments (2) | TrackBack (0)

December 19, 2006

ソフトウェア資産管理について考える

今月分の@IT連載記事が掲載されました。タイトルは「ソフトウェア資産管理について考える」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/10/01.html

| | Comments (0) | TrackBack (0)

« November 2006 | Main | January 2007 »