こんにちは。SREの近藤（@chaspy）です。 新しいサービス、あるいは Microservices を 本番環境へリリースする際、私たちは何を注意すべきでしょうか。 今回は、Production Readiness CheckList と導入方法について説明します。 Production-Readiness Checklist とは Service を本番環境へリリースする前の、信頼性観点でのチェックリストです。このチェックリストを事前に行うことによって、本番での Service 運用開始後の問題をなるべく引き起こさないようにする、あるいは起きたときに最善な手が打てることが期待できます。 Production-Ready Microservices (日本語版：プロダクションレディマイクロサービス ――運用に強い本番対応システムの実装と標準化 を読まれたひとも多いと思います。本書の付録

今回はソフトウェアエンジニアじゃない人や学生にも、ソフトウェアエンジニアという職業には夢があるかもしれないと思ってもらうために書いています。そのため既に詳しい方からすると回りくどい説明も多いと思いますがご容赦下さい。 基本的に記事とかには技術的なことしか書かないスタンスでやってきましたが、今回の件はさすがに誰かに伝えておくべきだろうということで長々と垂れ流しました。 概要 GW中に趣味で開発したソフトウェアを無料で公開したところAqua Securityという海外企業（アメリカとイスラエルが本社）から買収の申し出を受け、最終的に譲渡したという話です。さらに譲渡するだけでなく、Aqua Securityの社員として雇われて自分のソフトウェア開発を続けることになっています。つまり趣味でやっていたことを仕事として続けるということになります。 少なくとも自分の知る限り一個人で開発していたソフトウェ

社内でKubernetesハンズオンをやってみたのでおすそ分け。 参加者6人からバンバン出てくる質問に答えながらやって、所要時間4時間ほどでした。 SpeakerDeckにも資料を上げています。 https://speakerdeck.com/ktam1219/yaruze-kuberneteshanzuon (2019/07/11追記) 続編書きました！ -> 今度はあんまりゴツくない！？「わりとゴツいKubernetesハンズオン」そのあとに ハンズオンの目標 Kubernetesとお友達になる イメージを掴む 触ってみる(ローカル・EKS・ちょっとGKE) 構築・運用ができるような気分になる 巷にあふれるKubernetesの記事・スライドが理解できるようになる EKSがメインになっているのは、会社の業務でAWSを使うことが多いからです。 純粋にKubernetesを勉強したいだけな

本日（2019年1月24日）に拙著の最新刊『管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう』が発売となりました。kindleでは先行発売されており、既にレビューも頂いています。ありがとうございます。 「管理ゼロ」という強い言葉のタイトルになっていて、誤解される方もいるかもしれませんが、ただ管理しないという話ではありません。本書では管理がなくても成果があがる組織に変えていくための土台づくりから解説しています。 その辺りを知って頂ければと、「はじめに」だけとなりますが全文公開いたします。（著作全体を公開したいところですが、ご容赦ください） ちなみに詳細な目次はこちらで公開しています。 はじめに 「しっかりと管理するほど生産性が下がってきたように感じる」 「管理したいわけじゃないけど，生産性の上げ方がわからない」 こんな悩みを抱えたことはありませんか？同じ悩みを私も抱えてい

転職して7年が過ぎたというのを読んで気づいたんだけど、そろそろ入社後9年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ わりと重要でない Borgチーム (の周辺) いつのまにやらBorgという名前を普通に言って良くなっている。嬉しい。まあ当時もぶっちゃけ、秘密だから出してないっていうよりは、単に誰もアカデミア的なキャリアに興味が無いから出してなかったんだと思う(私見)。 さて、当時Borgというかクラスタマネージメントのあたりでは、コンピュータのリソースて適当にたくさん使ってるけど、これ節約したらすっげー支出減ったりしない？みたいなのがホットで、なんかとりあえず色々な人々が色んなことをやっていた。い

こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。 今回は、サイボウズ製品のひとつである kintone に対して行った性能改善の成果を紹介したいと思います。kintone は面倒なコーディング無しに業務アプリケーションのようなものを作ることができ、様々なデータを格納したり、複雑な条件で検索したりソートしたり、アクセス権もきめ細やかに設定したりできるというサービスです。この kintone はサービスの性質上、多種多様で複雑なクエリを発行します。またデータ量も膨大で MySQL だけで計数十テラバイトのデータが存在しており、クエリの処理時間が長時間かかってしまうこともあります。 サイボウズでは kintone の性能改善に力を入れており、今回はその成果を紹介しようと思います。 はじめに kintone はテナントごとに大きく使い方が異なり、性能改善が効くケースもあれ

kt60@ラブエロ雑誌で連載中！ @kt60_60 韓信がやった背水の陣 ・本隊で背水 ・敵はバカなので突っ込んでくる(敵がバカなのは事前に調べて知っていた) ・死ぬ気でがんばる ・別働隊が敵の城を占領 ・動揺する敵を一転攻勢 日本に輸入された背水の陣 ・死ぬ気でがんばれば何とかなる なんでや！！！ 2018-12-05 11:41:02

クレジットカード番号がログに残らないようにする fluent-plugin-pan-anonymizer をリリースしました カンムでは業務でお客様のクレジットカード番号を扱っています。お客様の安全のため、PCIDSSの要件をクリアするため、コンプライアンス遵守のため、カード番号は安全に取り扱う必要があります。この記事では対象をログに定め、ログに不用意にカード番号が残らないような仕組みについて書きます。 fluent-plugin-pan-anonymizer端的に言うと、こちらの fluent filter plugin を開発し、このプラグインを経由させることでカード番号がログに記録される前にマスクしています。 https://github.com/kanmu/fluent-plugin-pan-anonymizer プラグイン名に入っている PAN は Primary Account

ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス

【レシピマンガ】とにかく一度は食べて欲しい！ サバ缶をまるごと使った鍋がなにかと最高すぎた【晩酌天国】 サバの水煮缶は、いろいろな応用ができるうえにDHAも豊富で身体にもいい万能食材。しかもコスパもいいし、料理もカンタンといいことずくめ。今夜はこんなお鍋でポカポカに温まるのはいかがでしょうか。 www.hotpepper.jp 書いた人：なかむらみつのり 主に食や体験ルポ漫画を中心に活動。 1999年ヤングマガジンにてデビュー。 「ももちゃん先生料理のやくそく」（少年画報社）デジタル書籍「夕焼け商店街〜営業マン寿くんの寄り道ごはん」（ぶんか社）など発売中 Twitter：@JETNAKAMURA 過去記事も読む

先日、AmazonECS / Fargate 本番運用のための構築とデプロイ方法まとめというタイトルでECS/Fargateを本番運用するための構成とデプロイについての記事を書き、HiromuMasuda/ecs-deployというデプロイ用のスクリプトを公開しました。 すると、ECS/Fargateを用いた時のカナリアデプロイの手法が意外と話題になったため、前回は簡単に紹介してしまったカナリアデプロイを、今回は少し首を突っ込んで紹介したいと思います。 アーキテクチャ全体像 全体像はこちらです。 ECS/Fargateってなんだ？という方や、まだ全記事を読んでない方はまずはこちらを見てください。 AmazonECS / Fargate 本番運用のための構築とデプロイ方法まとめ カナリアデプロイをECSで実現する service内でtaskが2台動いている状態から、カナリアデプロイをして33

10月17日、AbemaTVウルトラゲームスチャンネルにて毎週水曜日夜9時から配信する「にじさんじのくじじゅうじ」の初回放送が行われた（ニュース記事、番組URL）。 バーチャルライバーグループ「にじさんじプロジェクト」に所属する月ノ美兎（つきのみと）ちゃん、樋口楓（ひぐちかえで）ちゃん、静凛（しずかりん）ちゃん、物述有栖（もののべありす）ちゃん、剣持刀也（けんもちとうや）くん、えるちゃん、家長（いえなが）むぎちゃんという7人が、番組発ユニット「Abema７」として出演。 3Dプラットフォームサービス「バーチャルキャスト」を利用し、番組のために作られた特別なセットで撮影した。人気メンバーが多数出演する番組ということで、多くのファンが集まり、最終的に視聴数が約19万9000回、コメントが約6万2400回と驚異的な数字を叩き出した。 出演者全員、3Dの体を「受肉」 番組は、「委員長」こと月ノ美兎

最近ようやく開発ツールとして Docker が手に馴染んできたので、タイトルの件も含めていくつか雑多に書きます。 CLI ツールを Go で書いて Docker イメージとしてリリースする コマンドラインツールを Go で書く、というのは以前からやっていて、主な理由としては「クロスコンパイルができるのでバイナリリリースが簡単」というのがありました。便利なので、クロスコンパイルから GitHub へのリリースを一発でやってくれるラッパーツールを書いたこともありました (一応動くものの、開発は非常に中途半端なところで止まってますが) gox して ghr するツール ggallin 作った その後、2017 年に入って Docker で Multi-Stage Builds という機能が実装されてからは、Dockerfile 内の build ステージで go build したバイナリを最終的

GoのAPIを書くとき、参考になるユニットテストの話は非常によく見ます。Table Driven Testをしましょうとか、サブテストの実行とか、そのあたりの話はたくさん書かれています。 また、テストキャッシュなども出てきましたので、ユニットテスト周りの機能・ノウハウは充実していると感じてます。 一方で、httptestを使ってテストサーバーを立て、リクエスト/レスポンスの内容を検証する場合、単一のリクエストを検証する程度のサンプルにとどまっていたり、あまり共通でこういう処理を書いてるよ、みたいなノウハウがなく、自前で一から書くとなると非常に腰が重くなります。 事実自分はそういう経験をしました。そういった共通処理は普段internalパッケージの中の、testutilsとしてまとめる、などしています。 今回はGoで上記のようなテストを書く場合、どういう共通処理が必要となったかをテーマとして

はじめに 先月、初めて「ペアプロ」なるものを先輩エンジニアに行ってもらいました。その際にとても学びになったので、その学びをメモしておこうと思います。 先輩とペアプロをする予定の新人エンジニアの方には「ペアプロからこういうことが学べるよ」ということ、ペアプロで新人を育成する予定のベテランエンジニアの方には「新人はペアプロでこんなことを感じるよ」ということが伝わると嬉しいです。 ただ学びと言っても、既にこの記事にまとめられていることが全てだったかなと思います。 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 こちらの記事はベテラン×新人のペアプロで、ベテラン側から書かれた記事であったため、ここでは新人側の目線から「具体的にどういう点が学びになったのか」ということについて書ければと思います（タイトルもパクってます）。 因みに「そもそもペアプロとは何ぞや？」という方には、こちら

こんにちは。ミネムラコーヒー（id:minemuracoffee）と申します。WEBサービスのディレクターを仕事にしています。*1 いつからだったか忘れたのですがExcelが好きです。アドテクまわりの仕事でなにかと社内でも業務基盤っぽいことをすることが多かったもので、いわゆるExcel職人です。 そこまで大したスキルでもないけれども、たいていどこに行っても小規模なフロア内では頼られる方という多いという自己評価があります。そのあたりの気持ちについてはこのエントリの中で示される過去の記事を読んで感じ取ってほしくて、読んだ上で「その程度か小童」と思われるあなた、僕を弟子にしてください。 2年半ほど前に今の会社に来てからは、エンジニア中心の組織なのでOfficeは共通言語ではなくなって、GoogleSpreadsheetsをメインに利用するようになりました。程なくsplitはじめとした独自関数に圧

以前ソフトウェア開発者採用ガイドの読書感想文を書いたときに反響が思ったより大きかったので、エンジニア採用というテーマは関心が高いのだなと感じました。 上記感想文のエントリでも書いていますが、お手伝いしている会社の方などから「どうやったら良いエンジニアを採用できますか？」と聞かれることがよくあります。先のエントリでは「頑張るしかないですねとしか答えようがない」と書きましたが、頑張るとはいったい何を頑張るのか、きちんとまとめておいたほうが良いなと思いエントリをしたためる次第です*1。 あくまで僕はこう思いますという話で、この通りにしたからといって必ず良いエンジニアを採用できる保証はありません。あしからず。 想定読者 良いエンジニアを採用したい偉いひと、もしくは人事のひとです。 前提: 良いエンジニアとは このエントリでの「エンジニア」とはいわゆるweb系のエンジニア(例: サーバサイドエンジニ

JWTを使うことは難しい？ こんにちは、かとじゅん(@j5ik2o)です。最近、JWTに関する以下のブログが話題です*1。 どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org このブログで言及されているのは、JWTをセッションの保存先に選ぶことで「何が問題なの？」に書かれているリスクがあるよ、という話*2。確かにいくつか検討することがありますね。 auth0.hatenablog.com auth0の中の人？よくわからないけど、反論的なブログエントリが公開されています。この記事では、指摘の問題が起こらないように設計するのはあたり前では？という意見みたいです。まぁごもっともではないでしょうか。 私も技術そのものというより、要件に合わせて技術を組み合わせる設計の問題だと思っています。加えて、JWTを利用することはそんなに難しいことかという疑問があった