今行っているものはたいして数がないので、まとめておく。

他にもこれはいいよ！というのあれば教えてくださいませ。

ネットワーク系

ping

到達性の確認

traceroute -n

経路の確認 名前は引かないほうが早く出力される

nslookup

名前は引けているのか

arp -a

arp テーブルを見る 1つもなければ link down の可能性あり

netstat -rn

ルーティングテーブル どのセグメントに行くにはどのNICを通るようになっているのか

プロセスの確認

ps auxf

プロセス実行ユーザ
CPU 利用率
プロセス親子の依存関係 が分かる

netstat -anp

あいているポート番号
クライアントとのセッション(アドレス/ポート番号)
PID

サーバ状況確認

date

ログにタイムスタンプを残すため

w

現状のログインしているユーザ オペレーションバッティングしないように

top

ロードアベレージが分かる

free

メモリ使用量

df -h

残りのディスク容量

du [該当ディレクトリ] | sort -n

最も大きいファイル/ディレクトリが下に表示される

find [該当ディレクトリ] -mmin -15

15分前に変更、作成されたファイル/ディレクトリ

原因はおそらくwebサーバ～DBサーバ間のセッションがネットワーク的に不安定だったからだと思うけど、DBサーバで netstat -an すると 大量の CLOSE_WAIT のセッションが残ってしまって、MySQL の最大コネクション数にまで達してしまってwebの表示が出来なかった。

CLOSE_WAIT をいきなり消すことは出来ないので、早めに消えるようにしたいときは

tcp_keepalive_time

TCPセッションが確立されて検査が実施されるまでの時間
時間になると tcp_keepalive_intvl と tcp_keepalive_probes の値にしたがって検査を実施する

tcp_keepalive_intvl

次の検査を実行するときの待ち時間

tcp_keepalive_probes

検査の回数

のそれぞれの値を小さくしてあげればよい。

変更方法は vi で :wq すると error がでておこられるので、echo を使う。反映に再起動などはいらない。

# echo 10 > /proc/sys/net/ipv4/tcp_keepalive_time

# echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes

# echo 3 > /proc/sys/net/ipv4/tcp_keepalive_intvl

デフォルト値と変更後の値と CLOSE_WAIT が切れるまでの時間を表にする

緊急時だったのでこのくらいにして、期待通りに CLOSE_WAIT がどんどん消えていった。

今でもこの設定のまま様子見だけど、TCPセッションが確立されているものを切ってしまうわけではないので、問題はないのでは？と勝手に思っている

上記は一時的な反映をしたい時の実施方法で、OS再起動で消えてしまう。

消えないためには、

# vi /etc/sysctl.conf

net.ipv4.tcp_keepalive_time = 10

net.ipv4.tcp_keepalive_probes = 2

net.ipv4.tcp_keepalive_intvl = 3

を追記

# sysctl -w

変更を反映

# sysctl -p

確認

のようにする

• 参考サイト</p>
  • http://d.hatena.ne.jp/koseki2/20070331/closewait
  • http://unix-study.com/weblog+index.date+200704.htm

今さらながらにニコニコ動画を見まくってしまったりな訳ですが、ひさびさにすごいうまいの見た。

結構プロじゃなくてもうまい人はいっぱいいるし、YouTubeも見てきたからあまりびっくりしないのだけど、この人は安定感がありつつもちゃんと弾くし音がええよなぁ。

この方のマイリストはこちら

http://www.nicovideo.jp/mylist/7612494

http://www.nicovideo.jp/mylist/7532187

また練習しなくてはと思わされた＞1日坊主

10ヶ月しかいなかった前職でいっしょだった方々と久々に飲む。前回会ったのは今のプロジェクトに入った07年3月くらい？だったから、それからの変態的な経験をしてきた自分とは会っていなかったんだなぁ。

前職の様子

• 前職場はいまだ自転車操業だけど、売り上げは増やせていた</p>
  • メーカとの契約を終わらせたのが大きいかもしれないけど、数字をちゃんと追うことが定着しているようでうれしい限り
  • 増えた売り上げを人を増やすことに当てているので、キャッシュは貯まらんなので相変わらず自転車操業なのか
    • 後から思ったのは、人を増やして攻めるのは確かにありだけど、増やした人を既存フィールドで同じような動きをさせるか、違うフィールドで新しいアプローチをさせるかでだいぶ違うなぁと。おそらくあの業界は狭いので新しいフィールドを求めたほうがいいと思う。
• 売り上げているポイントが変化していた
  • 売り上げている場所や人が変わっていて結構意外ではあった。大型案件が取れてもそこから次同じ金額を取れることはまずないだろう。やはり単発になるのだな。
  • 人が成長して売り上げられてきているのは単純にすばらしいことだ
• エクストリームミーティングを注目しているのはすごい偶然だけどうれしかったなぁ
  • 実際やってきているのでそこらへんの経験話がもっとできればよかったかな
  • 売りもとの一緒に全国つないでエクストリームミーティングしてみるのは確かにありで、新鮮な発見だった。

最近とこれからを話ながら

• やっぱりどうお金を出してくれるクライアントを捕まえるかがカギ
• 単なるコンサルという響きで判断されないようにしなくては
  • コンサルという単語にはヒアリングして、いろいろ見た結果、これでどうですかと提案するみたいなイメージかな
  • もっと実践的にコンセプトから基本設計(リソースの選定含む)、詳細設計までやる。その後の運用ルール/ポリシーを決める。運用に必要な体制と人的スキルのレクチャーまで一貫してやれる。みたいな言い方のほうがいいかな。
• 一人でやってきてしまった10ヶ月間で仕事の実務上の割り切りというか悟りがあったのだろうな
  • ほとんどのコミュニケーションはメールで完結できる
  • 問題が生じたら瞬間的にその場で解決方法を決めて、手を動かす
  • 決まっていない状態を保持しない
  • 手を動かさない人はいらない、手を動かせる人と一緒にやる
    • 口だけで偉ぶっている人が存在できる世の中ではなくなっている
    • 他社でも一緒のモチベーションで同じフィールドにきて手を動かしてくれる人たちがいて、そういう人たちとやっていければ

確かにこの1年半くらいはいろいろあった。また、皆さんもいろいろあったけど、新しいことを見つけよう/やってみようというのが感じられて良かったな。

メンテナンス中に試せたのでメモ。

• 実験サーバ : HP ProLiant BL460c
• Windows : Windows 2003 Server SP1
• Linux : CentOS4.5(final)

• bonding 設定</p>
  • active/standby(primary/secondry) で preempt 方式
  • Windows : OS としては機能がないので、hp から提供されている Utillity をインストール/設定する
    • ここ から HP Network Configuration Utility for Windows Server 2003 を選んでダウンロードできる
    • 設定は パス評価タイマ間隔 3秒(最小値)
  • Linux : 前に書いた この方法 を参考に miimon=100msec

• 実験方法</p>
  • 各サーバの active 側NICにつながっているスイッチポート間をはずす
  • その間サーバにて ping www.nikkei.co.jp -t をしておく
  • ping NG になってからどれくらいで OK になるかを計る

• 結果</p>
  • active 側を切ったとき primary => secondry</p>
    • Windows ping 5～7発前後でOKになる
    • Linux ping 1発も落ちず
  • はずしたケーブルを元に戻す secondry => primary
    • Windows ping 10発前後でOKになる
    • Linux ping 1発落ちる

最初の切替りより、切り戻し時のほうが時間がかかる。

ツールの性能次第になってしまったが、Windows は切り替わり時間がかかった。5秒以上の断はインターネットバックボーンから見るとまずい。

それに引き換え、Linux のパフォーマンスはすばらしいなぁ。Unix/Linux のネットワーク周りの機能は本当に充実している。

という意味ではサーバは Unix/Linux でといいたいが、Windows のほうが開発しやすいという意見が強いのが困ったところだ。

休みの日に家にいても閉塞感がただよって外に出たくなる。江ノ島は混んでいるいるだろうから山へ、ということで高尾山まで行ってきた。

午前中出発電車で高尾山口まで～リフトに乗ってある程度上まで行く～サル園見る～茶屋で昼飯食べて下りる～夕方前に自宅に着く。結局山の上は目指さず、リフトに乗っていけるところ＋少し歩くくらいの場所まで。

山から見る住宅地や新宿の高層ビル群を見ると、普段仕事している場所は一部のすごく特殊な環境で毎日過ごしているんだなぁと思う。緑のある場所には簡単に行けるのにそこを見ないように、触れないようにして過ごしている気がした。

確かに暑かったし汗は出っ放しになったけど、山の中は日陰は涼しいし下りるころは少し風も吹いて過ごしやすかった。

何しろたくさんの緑と広い眺めに自分の頭もリフレッシュできた。そういえば山に登ったのは何年ぶりだろうか。

今度また来よう。その時はもう少しちゃんとした格好をして、リフト使わずに歩いて山頂まで登ってみようかな。

大学生のころ4年間にちょっと高めな居酒屋さんでアルバイトをしていた。社会人になってからも2回ほどお客として行ったりしていたけど、結婚してから自分も引越したこともあって行かずじまいになっていた。

そのうちそのお店が入っているビルが閉鎖されてお店はどうなったのか心配したけど、割と近くの駅にお店を構えたとの情報より行ってきた。

約10年ぶりの再開。若干ドキドキしながら真新しいお店に入る。

マスターも店長も白髪は増えたけどみんな元気そうだった。不思議とあのころ一緒に働いた人とお客さんの名前が次々出てくる。あのころが一番良かったよ。と言ってくれた店長の言葉が妙にうれしかったり。

世の中を何も知らない18歳の時からだから、今振り返ると社会の縮図のようなものを感じられた時期だったんだなぁと自宅に着いてからふと思う。バブルがはじけてお客さんが減ったり、人がいなくなって足りなかったりしながらもお店はなんとか営業するとか、お客さんと仲良くなるとか。

メニューやお酒も増えていたけどみんな味は変わらずおいしかった。それがうれしかった。

お店にとっては色々ありながらも変わらぬ味で10年以上やってきている訳で、それをコツコツやってきたことが最近の自分の感覚と差があって新鮮だった。

若干興奮して色々しゃべってしまったけど、妙に素直な開放した自分がいてそんな時間が持ててよかった。

また、行こうと思った。

味処 ポパイ

O氏は最初の会社の同期。ベンチャーの立ち上げなども経験しつつ今は携帯キャリアで端末の開発/マーケティング/売り込みなどをやっている。K氏はO氏の幼なじみで現在IT系ベンチャーのCTO。

自分の考えとは異なる方向性が二人にはあった。それが結構意外というかここまで異なることもあることが結構新鮮な発見だった。ちょっと落ち着いてその差が生まれる原因を整理してみる。

彼らの主張は以下。

• 最初から会社はヤフーや楽天を目指すところから始める
• 組織にいながらも自分のやりたいことをやれる場所にいる
• 梅田望夫の本にかぶれて気軽にwebで勝負する人が増えてしまった
• 結局プロダクトというよりマーケティングなのだ
• 普通の社員がオペレーションしても儲かる仕組みが大事

考え方の比較をしてみる。

会社とは

VCなどの外部も含め資本が入ることで出来上がる
0円起業でも可能

志向性

いかに良いと思われるようになるか
徹底的なプロダクト志向

何を信じるか

お金を生むビジネスモデルが大事
高いレベルの技術力とスピードがイノベーションを起こす

人

普通でも着いてきてくれればいい
発想力、コミュニケーション力、技術力、実行力がそれなりにあるエンジニアしかいらない

考え方の元になるよりどころが違うからなのだろう。確かに彼らのよりどころは現状の日本の中で通じるやり方で、実際実績を作っているという意味でも正しい。さて自分の主張はweb2.0的なインターネットとエンジニアを信じきった先にある成功を夢見ているので確かにリスキー。ただ、このリスクに自分の全てをかけた時に何が起こるかを見てみたいからまだ信じている。という感じかな。

結果は2年後くらいにはっきり出るだろうから。こちらはこちらで頑張るさー。

ここ1年くらいインターネットビジネスに関わる中でエンジニアってこれからどう振舞っていくのかと考えてきてて、最近ある結論を出そうと思っているのだけど、一足早く紹介されてしまった。

技術力が高い人こそ、ビジネスモデルの良し悪しにもっと敏感になるべき ちょっと視点は違うのだけど、エンジニアに求めるスタンスとしては一致している。

これでは技術者と戦略家の利害はどんどん対立してしまいます。この悪循環をくい止める唯一の方法は、技術者が ──特に、優秀であればあるほど── ビジネスモデルの良し悪しを嗅ぎ分ける嗅覚を持つことです。誰が優れた「儲ける仕掛け」を生み出すことができるのか、技術者が判断できるようになれば、人月ビジネスから抜け出す見込みのない会社を見限ることができるようになるでしょう。

対称性を考慮すれば、戦略家が技術の優劣を嗅ぎ分ける嗅覚を持つことによっても、利害対立の悪循環をくい止めることが (理論上は) 可能ですが、高度に専門化・細分化してしまった技術を、技術者ではない戦略家に (優劣を判断できるほどに) 理解してもらうことは現実的とは思えません。戦略家と技術者が協力しあうには、まず技術者の側が相手を理解する必要があるのです。

優秀な技術者が事業にどれだけ貢献し得るか実感できれば、優秀な技術者に対して、その能力に見合った待遇 ──報酬はもちろんですが、仕事量を減らして OSS コミュニティへの貢献を推奨するなど── を提供すれば優秀な技術者が集めやすくなる、ということも実感できるようになることでしょう。

(snip)

技術者の待遇向上の鍵は、技術者がビジネスモデルの良し悪しにもっと敏感になること、すなわち会社における技術職以外の職種の役割についてもっと理解し、技術職以外の人達についても、その能力の優劣を見分けられるようになることにこそ、あるのだと思います。

エンジニアとして戦略家たちとどう組むかみたいな話はちょっと置いておいて、純粋にエンジニアが手を動かしサービスなり製品を作るのだからもっと自ら判断基準を持って作っていっていいんじゃないかということ。

作業や方向性に指示待ちをする人が多いけどそれはそこまでのレベルで、次のレベルはエンジニア自身の発想した作業、方向性を提示し続けて実際作って説得することだと思っている。その判断基準は思いつき程度ではもちろんダメで、世の中の情報や手法をそれなりのレベルで理解している土壌の上に生まれるのだけど。

そういう意味ではエンジニアは今までの 上から下 のしがらみを解いてもっと開放していい。一番早くて生き生きしたサービスっていうのはそういう動きがいろんなところでうごめいているんじゃないかと信じ始めているんだなぁ。