インシデントマネジメント 事態収拾のための取り組みに迫る Lunch LT でお話しした資料です
手を動かさないインシデント対応〜自動化で迅速・正確な運用を目指す〜
インシデントマネジメント 事態収拾のための取り組みに迫る Lunch LT でお話しした資料です
トラブルシューティングで僕が大事にしてること
2. 自己紹介 ・門田 矩明(かどた のりあき) ・株式会社CyberZ F.O.X サービスマネージャ ・元Javaエンジニア ・2006年新卒で中小系SIerに入社 ECサイト開発や金融関連システム開発 ・2012年 サイバーエージェント 中途入社 Amebaで出会い系アプリ → Teen女子ブログサービス(CANDY by Ameba) ・2014年 子会社のCyberZ に出向 → F.O.X プロダクトマネージャ → F.O.X サービスマネージャ now
もう「自動化」って言わなくてよくないですか｜Magnoliak
なんとなく、「自動化」って言葉のニュアンス、“今の状態にわざわざ苦労して付け加えてやること”みたいな、特別感出していませんか。 それより、わざわざ”手作業”でやる方を「手動化」って言った方が、よくないですか？ 「え？それ手動化でやるんですか、まだまだ人間じゃないと判断できない価値が有る作業なんですねー」みたいに。 どっちを特別視するか？って時に、より「当たり前の方」にはわざわざ名前つけないですよね。特別だと思っているから名前付けるので…だから、手作業の方に名前を付けた方が、その価値に気づきやすいんじゃないかって。 手作業の方が、直接的な作業時間以外にも、さまざまな意味でのコストがかかっていて…例えばどんな些細なことでも「判断する行為」は人の関心量を削って行くんですよ。 そもそも「自動化」の価値って、やってみると案外”自動でやってくれる”ことより、「作業フローが可視化される」「判断基準が明確
CIと食洗機 - Konifar's ZATSU
ソフトウェア開発の経験がない嫁氏と、たまに開発の話をする。いつだったか、たしか個人開発している時だったと思うが、CIとCDを先に整えておくのはとても重要という話をした。 仕事が終わってからもMacbookをいじっている自分に「今何してるの？」と聞かれたのがきっかけだった気がする。「開発に入る前の下準備だよ」「下準備って？」「やっておいた方がそのあとの効率がよくなることってのがいくつかあって、それをやってる」「たとえば？」「CI/CDの設定とか」みたいな感じ。そこからCIの説明に入った。ざっくりまとめると以下のような会話だ。 CIというのは、食洗機のようなものだ。我々も食洗機を使い出す前は「食洗機なくてもいいよね」という話をしていたと思う。しかし今はどうだ？食洗機がない生活は考えられない。食洗機をもっと早く買っておくべきだったという共通認識がある。 使い出す前はどうだったか。「何でも洗えるわ
Webサービスは振る舞いをモニタリングするべきって話 - そーだいなるらくがき帳
って話を明日のPHPカンファレンスでする予定でした。 PHPカンファレンス、私用のため私の登壇をキャンセルします。楽しみにされてた皆様、大変申し訳ありません。当日登壇予定だった内容はブログに細かく詳細まで記載して公開します。この度は皆様、ご迷惑をおかけします。 #phpcon2017 https://t.co/qgHogswYeI— そーだい@初代ALF (@soudai1025) 2017年10月6日 ここにあるとおり、雨の影響により、子供の運動会が延期になり、PHPカンファレンスと被ってしまいました。そこで色々悩んでいたところ、スタッフの方が気を利かせて連絡を先にくださり、キャンセルさせていただくことにしました。正直年に1度のお祭ですし、会いたい人も沢山いるイベントですから断腸の思いでした。しかも僕は今年各地のPHPカンファレンスに出れなかったので会えていないPHPerの方が多く居ます
[DO05] システムの信頼性を上げるための新しい考え方 SRE ( Site Reliability Engineering ) in Azure, on Azure
DevOps と並び、技術者の注目を集める SRE。このセッションでは Azure の「中」の SRE と、Azure 上でシステムを動かすユーザーの SRE、2 つの視点で解説します。システムの信頼性は気合でも手作業でもなく、エンジニアリングで高める時代です。障害に耐える組織と仕組みづくりとは? エモい話から黒い画面のデモまで、Azure における SRE の「いま」をお伝えします。 製品/テクノロジ: DevOps/Linux/Microsoft Azure/OSS/Windows Server/アーキテクチャ/クラウド/運用/事業継続 真壁 徹 日本マイクロソフト株式会社 クラウド & ソリューション ビジネス統括本部 クラウド ソリューション アーキテクトRead less
![[DO05] システムの信頼性を上げるための新しい考え方 SRE ( Site Reliability Engineering ) in Azure, on Azure](https://cdn-ak-scissors.b.st-hatena.com/image/square/56686890c437a2a4a96b2555281f477512b7db30/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fdo05-170616023431-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
DevOps時代のテスト要求分析 - Test Automation
はじめに こちらのエントリはソフトウェアテストAdvend Calendar2016の13日目の記事です。 qiita.com ちなみに、昨日のエントリ、テスターがエンジニアとキャッキャウフフしながら文言指摘軽減を技術的に30分で解消したかもしれない話 - テストする人。は、キャッキャウフフしてる感じが楽しそうですね。 DevOps時代のテスト要求分析は難しい DevOps時代のテスト要求分析は難しい。それは、ウォーターフォール時代のテストで基本として使われていたVモデルによる従来のテスト戦略をそのまま適用することが出来ないからだ。これにはいくつかの理由がある。 （理由１）ビジネスの成熟度によってサービスやプロダクトに重要な品質が変化する （理由２）開発中にシステムのアーキテクチャ設計が変化する このブログエントリーでは、これらの理由を解説したのちDevOps時代のテスト要求分析の方向性に
基礎からわかるDevOps #devfesta
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する 従量課金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 4. 時価総額ランキング 2016 2006 1. アップル (6091億ドル) 1. エクソンモービル (4470億ドル) 2. アルファベット (5434億ドル) 2. GE (3840億ドル) 3. マイクロソフト (4487億ドル) 3. マイクロソフト (2940億ドル) 4. Amazon (3969億ドル) 4. CITIグループ (2730億ドル) 5. Facebook (3683億ドル) 5. ガスプロム (3680億ドル) 5. 現在のビジネス状況 ✤ ビジネスの変化がどんどんはやくなっている ✤ VUCA => Volatility (不安定) / Uncertain
自動化よりまともに仕事ができるようにしよう：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■自動化できるかできないかのポイント 自動化ができるかできないか。これを見極める簡単なポイントがある。まず、自動化が実現されるプロセスを考えてみよう。まず、自動化する対象の業務が整理されているだろうか。手作業でやっても円滑に業務ができるかということだ。 対象の業務を整理せずに自動化を推し進めると、仕組みが複雑になり過ぎて破綻する。そもそもな話で、整理もされてない業務が自動処理できるというのも、都合が良すぎる話だ。まず業務を整理して安定して行えるようにしよう。自動化の話はその後だ。 自動化をしたいという要件は多く聞く。しかし、業務の手順を頑なに変えようとしない。こういうケースでは、業務が属人化している、例外処理が発生しやすい、フロー自体が整理されていない等、自動化以前
我流・Jenkins実践 概論 - Kengo's blog
日本の知人からJenkinsの使い方について相談したいというありがたいお話を頂いたので、具体的な話をはじめる前に自分が考えている総論についてまとめておきます。 なお私のJenkins歴は長くないですしコミュニティに対する貢献も残念ながら皆無です。ガキ大将が戦略論を語っているようなものだと思って気軽に読み流してください。 はじめる前に ゴール設定をしましょう。 Jenkinsは使い始めるのは簡単ですが、使用によって一定の効果を得るには意思が必要です。実際「1日になんどもビルドする」ことによる恩恵ってパッと思いつかない方が多いのでは？その状況で使い始めてもフェードアウトして終わりです。 「テストをすべてグリーンにする」「カバレッジを各メンバーが頻繁に確認できる状況を作る」「コンパイルエラーなコードをコミットする輩を血祭りにあげる」など何でもいいので決めて、チームで合意を得ておきましょう。 メン
開発者がアジャイルなだけでは十分な価値が生まれない、IBMのいう「DevOps」とは
開発者がアジャイルなだけでは十分な価値が生まれない、IBMのいう「DevOps」とは：IBM Rationalゼネラルマネージャ、クロックナー氏に聞く IBMはなぜ「DevOps」という言葉に独自の意味を与えているのか。米IBMが6月に開催した「IBM Innovate 2013」で、IBMソフトウェアグループのIBM Rationalゼネラルマネージャであるクリストフ・クロックナー氏に直接たずねた内容をお伝えしたい。 日本IBMは7月11日に、米IBMが4月に買収したUrbanCodeのリリース自動化製品の国内発売を発表すると同時に、IBMのいう「DevOps」とは事業部門、開発部門、運用部門のすべてをカバーするものだと説明した。IBMはなぜ「DevOps」という言葉をこうした意味で使っているのか。米IBMが6月に開催した「IBM Innovate 2013」で、IBMソフトウェアグルー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜ「Infrastructure as Code」が必要なのか
再発防止策を考える技術 / #phpconsen