JANOG37 発表資料です. gobgpd とBGP flowspec を使うことにより,ChatOps でDDoS 対策が可能になります. gobgp-node というNodeJS 向けgobgp クライアントを作りましたが,これをHubot に組み込むことで簡単にgobgpd を制御できま…
![Anti-DDoS Bot (gobgpd + flowspec編)](https://cdn-ak-scissors.b.st-hatena.com/image/square/4bfbde650251cbae3402163a1458ad5a3a1277f2/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F44b7f0039d7e4e3f972319ba70f95b9b%2Fslide_0.jpg%3F5794593)
GitHubが1月28日のサービス障害の詳細を公開。停電により内部のChatOpsシステムも落ちて初期対応が困難に。Redisクラスタの復旧に時間 報告では、サービス障害はGitHub社内のChatOpsシステムも巻き込んで初期対応に時間がかかってしまったこと、一時的な停電がRedisクラスタの障害を引き起こしたため、その究明と復旧が作業の主な部分だったことなどが説明されています。 報告の要点をまとめました。 内部のChatOpsシステムも障害に GitHubのサービス障害は、すでに報告されているように、自社データセンターにおける一時的な停電が最初の原因でした。 At 00:23am UTC on Thursday, January 28th, 2016 (4:23pm PST, Wednesday, January 27th) our primary data center experi
このブログをご覧のみなさま初めまして。@siroken3です。メルカリではインフラチームに所属しており、リリースの仕組み構築を担当しています。 メルカリのリリースについて メルカリではカスタマーサポートから受け取る改善要望、プロダクトとしてまだやれてないことなど多くのタスクがあり現在も継続して開発とリリースが行われています。 Issue管理はRedmine、ソースコードのリポジトリはGitHub privateを使用しています。Pull Request(以下PR)でのコードレビューを実施、masterブランチへマージされたものをリリースするのが基本的なフローです。 一方、1年前まではリリース頻度は週1回のリリース日を決めて実施していましたが、この1年で大きく変わりました。現在では日本版とUS版を合わせて10回〜30回/日の頻度でリリースしています。この記事では大きく変わったメルカリのリリー
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
ペパボでは、チャットツールとしてIRCを長らく使っていたのですが、先日、Slackに全面的に移行しました。その話を少し書いてみようと思います。 追記: 社長的にSlackに移行したほうがいい理由 | ペパボ社長ブログというエントリが出ていたので、そちらもご参照ください。 IRCの利用程度 そもそもIRCをどの程度使っていたかというと、職種や役職等を問わず、全スタッフ(アルバイト等も含む)が使っていました。つまり、エンジニアも総務も、マネージャーも社長もみんなIRCにいて、そこでフローのコミュニケーションを行っていたということです(ちなみに、情報のストックや、チャットには向かないような共有にはGitHub Enterpriseを使っています)。また、サーバの状態監視等の様々な通知や、いわゆるChatOps的なこともIRCでやっていたので、人間もbotもとにかくたくさんいて、賑やかな状態です。
こんにちは!BrainWars 遊んで頂けてますか? 最近はcocos2d-xを勉強中で、BrainWars内の「ドライブ ザ ギア」というゲームを作りました。 まだ綺麗な実装には程遠い。。。引き続き勉強しまくらねば。 新ゲーム「ドライブ ザ ギア」を追加しました! A new game "Drive The Gear" added:) pic.twitter.com/1ZZBtvqbmE— BrainWars (@brainwars_jp) February 25, 2015 という感じで、インフラとかフロントとか関係なくいろんな技術にチャレンジ出来る楽しい会社です。 弊社に興味ある方、お待ちしております! 本題 さて本題。 弊社では、昨年10月からコミュニケーションツールとしてSlackを採用しています。 そしてSlackの採用とともにChatOpsを推し進めてきました。 ChatOp
障害発生の際など、やむをえず自宅で就寝中の社長を起こさないといけないことがある。インターネット時代においても遠隔地にいる人間の意識を強制的に遮る有効な方法は一つである。電話だ。 普通の人間なら順番にただ電話すれば良いのだが、我々は電話恐怖症を患うエンジニアである。過去のトラウマから誰かに電話をかけることが不安で仕方ない。 さらにはリモートワークの環境だと、アメリカ西海岸にいる社員が日本の電話番号に電話するのは色々と敷居の高さがある。素早く簡単に社長に電話し不機嫌にすることなく即座に目覚めさせる方法が必要だ。 このような課題を、我々が対処する方法はただひとつ「自動化」である。機械に電話させればよい。行末スペースをただひとつも許せないほど繊細な心を持つ我々と比べて、機械は感情がないので不機嫌な人間に当たられても何も感じない。 今回は、感情のないロボットに社長に電話させる方法を紹介する。 Twi
以前、Slackの検索機能を強化するSSlackをリリースしましたが、今回は引き続き、アプリケーションからSlackへの投稿を円滑にするSlack Anywhereを公開しました。 本記事では、その開発の経緯や使い方を説明します。 開発の背景 WebPayは私を含め、遠隔地で勤務しているメンバーが多いため、ChatOpsを積極的に取り入れています。 Slackは多くの外部ツールと簡単にインテグレートできる点でChatOpsにぴったりです。 しかし、用意されているものでは不満が出てくるのが技術者の性です。 導入当初から、より自分たちのオペレーションにマッチした機能に改良し、業務を効率化するために連携機能の開発をすすめてきました。 Slackに繋ぎこむサービスをつくるのではなく、手製ツールからSlackに通知を飛ばす場合、おもにIncoming WebHooksとSlack APIを使います。
トレタで使っている、チャットで勤怠管理する「みやもとさん」をオープンソースでリリースしました。 https://github.com/masuidrive/miyamoto Slackの#timesheetsという部屋で、「おはようございます」と書き込みと出勤が記録され、「お疲れまでした」と書き込むことで退勤となります。「明日はお休みさせて頂きます」と書き込むと、休暇の届け出になります。 チャットで勤怠管理する最大のメリットは、オフィスに居なくても誰がいつ出勤・退勤したのか全員が分かることにあります。出退勤管理アプリは色々出ていますが、営業で直行直帰する人や、リモートワーカーなどは、帰った時間がリアルタイムでわかりにくいという欠点があります。 「みやもとさん」では、チャットでやりとりする事でみんなの見える形で出退勤が記録され「あ、帰る前にあれも!」など、ありがちなコミュニケーションがスムー
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く