SREチームの藤原です。今回は、SREチームが主導してポストモーテムを書く取り組みを、社内で1年半ほど運用してみたという話です。 ポストモーテムとは? 「ポストモーテム」(postmortem=事後検証)とは、システムにインシデントが発生したことによる影響、緩和や解決のために取られた行動、インシデントの原因、再発防止策などをまとめた文書です。 カヤックのSREチームは、各メンバーがそれぞれのプロダクトに参加し、他のエンジニアとともに開発と運用を行う、いわゆる「Embedded SRE」という形態を取っています。そのため、SREチームのメンバーでも自分が関わっていないプロダクトで発生したインシデントについては詳しく把握できないことがありました。SRE以外で運用に携わっている、プロダクト専任のサーバーサイドエンジニアにはなおさら困難でした。 また、インシデント発生時に実際に手を動かす人がどうし

4月になり、新人が入ってくる季節になりました。技術部新卒研修担当の fujiwara です。 これまで弊社技術部では特に技術部としての研修というものを行っていなかったのですが、今年は何かやりたいねということで人事部に7日間確保してもらい、主に acidlemon と2人で新卒8人に研修をすることになりました。 研修の資料などは GitHub でプライベートリポジトリを作って作業しており、それをまとめたものを GitHub上で kayac/newbie-training として公開しています。 どのような内容にするかは事前に昨年度の新卒を含めたエンジニア陣で(社内勉強会でビールを飲みながら)話し合い、 現場で実務に追われてしまうと身につきにくい基礎的な内容 コードを書ける人は多いけどLinuxサーバの操作は不慣れな人が多いので、そのあたりを底上げする内容 をメインに構成してみました。また、7

777ブログウェイ「つくるための三種の神器」というテーマで、 本日はカヤック京都支社の技術部アルバイトで働いている高江洲（たかえす）がご紹介します。 エンジニアとして働く上で、大切だなぁと思う以下３つのことについて自分が利用している(利用し始めた、今後も継続したい)ことを３つ取り上げてみたいと思います。 1. 情報収集 2. タスク管理 3. テスト駆動開発 １．情報収集 情報収集手段といえば、はてブの人気エントリーやヤフーのトップニュース、RSSリーダーなど様々な手段がありますが、最近はもっぱらGunosy（グノシー）を使っています。 TwitterやFaceBookでログインすると、興味のある分野についてのおすすめ記事のまとめを1日1回メールで受け取る事ができます。大手のニュースサイトから個人のブログまでの幅広く、僕は朝の通勤中にひと通り目を通す感じで使っています。 使い始めて2ヶ月く

「つくるための三種の神器」というテーマで続けている「777ブログウェイ」! 9日目となる本日は「Rubyで開発するときに入れておきたい三種のRubyGems」と題して、定番の RubyGems を3つご紹介します。 1. bundler「bundler」は、アプリケーションが依存するgemを管理するツールです。今やgem管理のデファクトスタンダードです。 「gem install hoge」のようにコマンドで gem をインストールしていくと、あれよあれよとグローバルな領域にどんどん色んなgemが…それも複数バージョン混在していきます。そして、いずれは、このアプリケーションで必要なgemはどれだっけ…バージョンはいくつだっけ…といった具合に、どんどん依存関係が分からなくなってきます。ここで活躍するのが「bundler」です。 使い方はいたって簡単。1) bundler のインストールgem

最近Androidとの抗争が激化しているago（@kyo_ago）です。 jQueryはCSSセレクタを多用する特徴がありますが、jQuery内では実行ブラウザやCSSセレクタの記述によって呼び出されるブラウザAPIが変わり、それによって実行速度にも影響が出ます。 この記事では「セレクタAPIとはなにか」、「CSSセレクタの記述によって呼び出されるセレクタAPIの種類」、「高速なセレクタAPIを使用するための方法」、「高速なセレクタAPIが使われるかどうか確認する方法」などを紹介したいと思います。 （※この記事はJavaScript Advent Calendar 2011 (フレームワークコース) : ATNDの1日目の記事です） セレクタAPIとはなにか セレクタAPIとは「#hoge .huga」のようなCSSセレクタから、DOM上に存在する要素を取得するためのAPIです。 jQue

入社4年目にもなってtech.kayac初登場のせいです。 ブログ書けプレッシャーにとうとう屈する時がきました。 これで夢にkyo_agoが出てうなされなくてすみます。(彼はtech.kayacの尻たたき担当でした) 先々月「ぼくらの甲子園!熱闘編」というゲームをモバゲー内にてリリースしました。 これは去年リリースした「ぼくらの甲子園!」の続編です。 モバゲーユーザの方、是非遊んでみてください。 今回はこの「ぼくらの甲子園!熱闘編」がどういうインフラ構成になってるか紹介したいと思います。 注) 題名に「カヤック流」とはつけましたが、カヤックでは多様性を善としている風潮があり、 ゲームによってインフラの構成が違うどころか、利用しているプログラミング言語すら違います。 なので全てのゲームがこのような構成になってるわけではありません。 前提 今回のインフラ構成を決めるに至って考慮した点は「ラクに

このまえ登り坂の途中でロードバイクのタイヤが破裂しました。ながたです。 今回はバッチ処理について書いてみようと思います。 バッチ処理？ Webサービスの処理開始条件は、大まかに次の2つに分けることができます。 ユーザーのアクションに起因するもの ユーザーのアクションに起因しないもの このうち後者の処理をバッチ処理が担当することになります。 バッチ処理の担当分はさらに、 特定の条件（時間やサービスの状態）で実行するもの 手動で実行するもの の2つに分けられます。 今回はこの「手動で実行するもの」について書きたいと思います。 バッチを手動実行するのはどんなとき？ バッチ処理を手動で実行するのは、十中八九イレギュラーな状況が発生したときです。 ルーチンワークや実行の条件が決まっているものは何らかの方法で自動化できるはずです。 そしてイレギュラーな状況のほとんどは不具合が発生したとき。 つまり 重