チーム練習
チーム練習
午前中から雨。その後雪。ものっそい雪でしたね。午前中に環境が揃っているところへいって、昨日作成途中だった総会資料の仕上げ。
プリンタとか、筆記用具とかちゃんと揃っているところじゃないとできません。ざっと完成させてからこんどは戸越体育館でチーム練習。
こんな状況の中、結構な人数が集まりました。
練習終了後にワークアウトをこなして、食事してから帰宅。
ワークアウトと総会資料作成
ワークアウトと総会資料作成
土曜日ですが、相変わらず割当てがありません。午前中に近所の公園まででかけてワークアウト。さすがに普段の土日よりは人出がすくなかったような。
朝はまだちょっと気温がひくかったのでTシャツにパーカーで出かけたんですが、お昼にかけて気温があがってきて午後はTシャツだけでOKな気温に。
午後は環境が揃っているところへ行って審判員総会資料の作成。総会そのものは中止になりましたが、資料は作成して配布するとのこと。
実質的な締切がなくなったに等しいのですが、そこはちゃんと締切を設定してやらないと。逆に自分で設定しないとやらない自信まである。
暗くなるころまでに目鼻をつけて帰宅。
在宅勤務とか
在宅勤務とか
都知事閣下の要請に従い、自分のも在宅勤務の指示。といっても指示がきたのは木曜日の20時すぎ。決定が遅い。
で、金曜日は在宅ねってことでやってみたんですが、まぁできませんね。
物理的な環境がない
少なくとも机と椅子、それに2m×2m程度のパーソナルスペースが必要だと思う。
それに、おおきなディスプレイと、それなりのキーボードも。ノートPCがあればいいってなことじゃない。
気分の切り替えができない
もう30年も「通勤」→「仕事」というルーチンをこなしているので、さあ仕事っていったってできない。
気分の問題だけど。
ネットワーク的な制限
ネットワーク的な環境はちゃんとしているし、いざと慣ればSSHでなんとかするんだけど、自分がいつも使っている環境にくらべるとストレスが高い。
あ、これができないとか、あれができないとか。
カラダがきつい
椅子がないので地べたに座ってノートPCなんですが、そんな姿勢何時間も続かない
ってなことで午前中でギブアップして出社。
無理です。諦めました。
chefのtemplateファイルへif文を入れる
chefのtemplateファイルにif文を入れる
3月17日のエントリでrecipeファイルからtemplateファイルへ変数を渡す話をかきました。
どうやらtemplateファイルにもif文がいれられる模様。レシピ側でif文をかいて、それに対応する変数を渡すか、template側で既知の変数に対応するif文を入れるかの違いですが、たぶん後者(templateにif文を入れる)方がスッキリかけるような感じがします。
実際に利用したのはapacheの設定ファイルの展開。
編集用と公開用でほとんどいっしょなんだけど、編集用の設定ファイルには一行ディレクティブを追加必要があります。
@suffixという変数に編集用だと"edit"という文字列が入っています。その場合に "Hoge fuga"というディレクティブをいれる。
こんな感じ。
<%= if @suffix == "edit" then "Hoge fuga" else "" end %>
もしかして、rubyの構文ならなんでもいれられるのかもしれない。
こんどやってみよう。
Oracleに障害
Oracleに障害
いくつかのWebアプリケーションから反応が遅いとのレポート。いつもどおりに「遅いんです」とか「ぐるぐるして終わりません」とかっていう自分語でレポートしてくるので、どんなURIへどのようなリクエストをだして、どのような反応があったのかを定量的に報告してくれといったんは返す。
自分語で喋ってくれたなかのキーワードを整理すると、どうやらOracleDBを参照しているアプリケーションというのが共通点らしい。
早速OracleDBが動作しているサーバをチェックするとCPU負荷が偉いことになっているのを発見。まぁわかりやすい障害ですね。
どうやら特定のクエリがデッドロックしているか、暴走しているかしているようでCPUリソースをほとんど食いつぶしていることが判明。
当該インスタンスを再起動。shutdownがいつまでも終了しないので、当該プロセスをkill。
本当ならそのプロセスがどんなクエリを発行していたかまで調べるのが常道なんでしょうけど、運用担当者としては復旧の方が重要なので。
短時間で劇的に回復。当たり前か。
CPU負荷の経緯はこんな感じ。Zabbixで検知できなかったのはトリガーの調整不足。
httpsでクロールするとエラーになるとか
httpsでクロールするとエラーになるとか
自社ウェブのコンテンツをクロールして、索引を作ってくれる会社と契約をしています。こっちが用意したXMLファイルをGETしてそこに列挙されているURIをクロールするという動作をしている模様。全部クロールすると10時間ほどかかるみたい。
先々週あたりにL2スイッチとウェブサーバの間にちょっとした機械を挟んだところ、そのクロールがエラーになるといいます。そのちょっとした機械はL2レベルでSSLを復号化して、FWに通して、また暗号化してWebサーバへ流す機械。TCP的には入ってくるパケットと出ていくパケットは同じはず。透過的に動作していると思う。
上記のクローラは列挙されているURIにまずHEADを発行して200が帰ってきたらGETするという動作をしているとのことで、最初のHEADが全部じゃなくて、30%くらいエラー(empty body)になるというのです。サーバ側のログではそのエラーになるHEADコマンドに対してもちゃんと200で返していて、FWでもブロックはしていないので、リクエストをだしたところにはちゃんとレスポンスを返していることになっている。
ためしにその「機器」を外してみるとエラーにはならない。うーん、よくわからないぞ。
ちなみにクローラ社側で別機器から同一クローラでやってみるとエラーにならないとのこと。
現象がでているのがそのクローラだけなので、当該アドレスからのリクエストはHTTPSを通さないようにして回避。徹底的に調べるのも面白いでしょうが、実用的じゃないところは思い切って切り捨てることも必要。
