データ基盤チーム0人で運用は回るのか？！ 前人未踏チャレンジ・クックパッドデータ基盤のすべて2020 - クックパッド開発者ブログ
技術部データ基盤グループの青木です。 ここ1、2年はなぜか成り行きでBFFをでっちあげたり、 成り行きでiOSアプリリニューアルのPMをしたりしていたので あまりデータ基盤の仕事をしていなかったのですが、 今年は久しぶりに本業に戻れたのでその話をします。 突然の1人チーム、そして0人へ…… 今年のデータ基盤チームは消滅の危機から始まりました。 間違いなく去年末は5人のチームだったと思うのですが、 メンバーがイギリスへグローバルのデータ基盤チームを作りに行ったり、 山へ検索システムを直しに行ったり、川へレシピ事業の分析業務をやりに行ったり、 海へ広告のエンジニアリングをしに行ったりするのをホイホイと気前よく全部聞いていたら、 なんと4月から1人だけのチームになってしまいました。 事はそれで終わりません。 恐ろしいことに10月にはわたし自身も育休に入ることになったので、 10月はデータ基盤が0
運用業務の設計思想 /20190520-awsj-pro-operation-design
5/20(月)開催のAWSプロフェッショナルサービス勉強会での発表資料です。 (注意) 現時点での総まとめ的な資料なので250ページ超あります。あらかじめご了承ください。 # 発表の概要 多くの運用現場において、経営・マネジメント層からの「運用自動化」要求や、業務の多様化や業務量増大により、「運用自動化」を進めざるを得ない状況に追い込まれてきています。 しかし、運用自動化には多くの不都合や副作用があり、意図に全く反した結果をもたらすことの方がむしろ多いのが現実です。 今回は、比較的大きな組織の中で、(運用業務の自動化を含めて)「変化に強く、スケールおよび持続可能な運用」を実現するために、どのような取り組みが必要なのか解説します。 # アジェンダ 1. 運用自動化、不都合な真実 2. 運用業務の「構造化」という大前提 3. 「運用業務」構造化の例 3.1. 「運用」の定義 3.2. 「運用価
2019-03-06 ダメな「運用自動化」の3類型 + α /operation-automation-3-bad-model
ssmjp 2019/03での発表資料です。 「運用自動化の基本原則」シリーズの番外編と位置付けています。 # 運用自動化の基本原則シリーズ - 2019-03-06 「運用自動化」とは: https://speakerdeck.com/opelab/20190306-operation-what-automation - 2019-05-24 運用業務の「構造化」: https://speakerdeck.com/opelab/20190524-structured-operation - 2019-04-18 運用自動化の基本原則1 「引継ぎの原則」: https://speakerdeck.com/opelab/20190418-operation-automation-basis-principle-1 - 2019-05-24 運用自動化の基本原則2「平易化の原則」: https
AWS特有の運用イベントまとめ（非障害系） | DevelopersIO
【ACM】 サーバー証明書の有効期限切れ／自動更新失敗 ACMは、CloudFrontとELBと連携してサーバー証明書を提供するサービスです。 ACMで発行する証明書は1年毎に更新する必要がありますが、基本的には自動更新されます。 ただし、場合によっては自動更新が失敗するケースがあります。 検証の仕組みは、以下のドキュメントを確認してください。 自動ドメイン検証の仕組み 自動検証に失敗した場合、EメールおよびPersonal Health Dashboardで通知されます。 自動検証に失敗した場合 また、外部で発行された証明書を利用している場合は、手動で更新する必要があります。 再インポートの手順は、以下のドキュメントを参照してください。 証明書の再インポート EV証明書が必要なケースでも無ければ、ACMで証明書を取得してオペレーションが発生しないようにしておきたいですね。 【Route
Well-Architected を目指した改善と組織文化への影響 | CyberAgent Developers Blog
（弊社デザイナーが作ってくれた私の LGTM 画像です） Developers Blog に初登場！クラウドファンディングプラットフォーム Makuake の吉田慶章 ( @kakakakakku ) です．Makuake には約1年前に JOIN しました．JOIN した直後はサーバサイド開発をメインに新機能の開発を担当していましたが，2016年3月頃からウェブオペレーションエンジニアも兼務し，インフラ構成やアーキテクチャの改善をしたり，DevOps 文化の推進をしています． どんなサービスにも「技術的負債（もしくは何かしらの課題）」はあると思います．特に成長期のスタートアップでは，新機能をリリースすることを最優先に開発をする場面も多いですし，またサービスの急激な成長に伴って，今までは問題なく稼働していたアーキテクチャが，突如運用に耐えなくなってしまうこともあります．ある意味で「技術的負
AWSで構築した環境にありがちなシェルスクリプトたち まとめ ｜ DevelopersIO
AWSでサーバを運用する際にはEC2からAWS CLIを使って他のAWSのサービスと連携したりすることがあると思いますが、AWS環境ならではのシェルスクリプトを集めてみました。AWS CLIのバージョンは1.7.13、Pythonのバージョンは2.6.9を使っています。私はAmazon Linuxで動作を確認しています。 目次 準備する AWS CLIのインストール AWS CLIのアップデート aws configureでセットアップする IAM roles for EC2 instancesに関して 監視系 CloudWatchでカスタムメトリクスを設定する ZabbixからCloudWatchの値を取得する プロセス監視する バックアップ系 AMIとEBSのバックアップを作成する RDSのスナップショットを作成する S3のフォルダを削除する 便利スクリプト系 Route53の自動登録
ITに係る全般統制とDevOpsの緊張関係 - プログラマの思索
アジャイル開発に慣れている人から見ればDevOpsなんて当たり前に見えるが、DevOpsを阻む障壁として「ITに係る全般統制」がある。 ITに係る全般統制とDevOpsは真っ向から対立する概念と捉えた方がいいのではないか、と最近考えている。 以下メモ。 【参考】 開発と運用の新しい関係、「DevOps」とは何か？ － Publickey 全般統制,業務処理統制[ITの統制] 海外会計税務用語 :総合型税理士法人山田＆パートナーズ｜東京,関西,名古屋,福岡の総合税理士事務所 【DevOpsが変える開発と運用[＃1]】 DevOpsは開発と運用の分離と対立するのか？：情報インフラ24時 眠らないシステム：ITmedia オルタナティブ・ブログ 【DevOpsが変える開発と運用[＃3]】運用が権威的になると開発のやる気が損なわれる：クックパッドのチャレンジ：情報インフラ24時 眠らないシステム：
Software Design 2015年2月号『なぜ「運用でカバー」がダメなのか』読了 - そのねこが学ぶとき
Software Design (ソフトウェア デザイン) 2015年 02月号 [雑誌]posted with amazlet at 15.02.11 技術評論社 (2015-01-17) Amazon.co.jpで詳細を見る 読んだ。身に覚えがありすぎるもので（震え声） そもそもにして「運用でカバー」という言葉自体が思考停止しているというか、その実態は何で何が問題なのよ？というのをよくよく考えもせず「なんとなくまずそうだよね」状態で停まっている気がするのですが、そういうのをきちんと論理的に客観的に解きほぐして脱却していくってのは非常に重要なことだなと、この特集読んで思いました。たぶん、そういうこと他にもいっぱいある。 「運用でカバー」とはすなわち、「仕様外の依頼をなんとなくもやっと渡しても、運用現場の努力でなんかなんとなくやっちゃう」ってやつで、特集内ではその帰結として現場の高負荷、業
バッチ処理について再考 - プログラマでありたい
作業途中のメモです。バッチ処理の定義を確認しようとしてWikipediaをはじめとして幾つかのサイトをみてました。その時に目に入ったのが、下記の文章です。 利点 バッチ処理には以下のような利点がある。 ・多くのユーザーがコンピュータのリソースを共有できる。 ・処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。 ・人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。 ・高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。バッチ処理 - Wikipedia これだけみると、人件費に対してコンピュータリソースが高い時代の産物なんですよね。今は、クラウドの登場で、有り余るコンピュータリソースをほぼ自由に低コストに使える時代です。そもそもバッチ処理である必要があるか、考える必要がありますね。特に夜間バッチにつ
運用自動化ツールまとめ 2014年版――国内／外資ベンダー７社の製品・サービスを一挙解説
運用自動化ツールまとめ 2014年版――国内／外資ベンダー７社の製品・サービスを一挙解説：特集：運用自動化ツールで実現する、クラウド時代の運用スタイル（4）（1/7 ページ） 第3回までオープンソースソフトウェアに焦点を当てて、「サーバー監視」など個々の作業の運用自動化を解説してきた本特集。今回は商用ツールが得意とする「個々の作業を連携させた一連のプロセスの自動化」にフォーカス。国内外の統合運用管理ツールベンダー主要7社の製品・サービスを一挙に紹介する。 マルチクラウド、OpenStack、SDx、DevOps――各種トレンドのキーワードとなる運用自動化 ビジネスにアジリティが求められ、それを支える手段として仮想化、クラウドが広く浸透している今、運用自動化はビジネス要請に迅速に応える上で大きな鍵を握っている。というのも、オンプレミスで物理／仮想のサーバー数が数十台、数百台の規模ともなれば、
社内LANをすっきりさせるLANケーブル配線＆結線ルール
LAN配線ルール２ 「埋めるケーブルはタグを付ける」 フリーアクセスの床下に埋めるケーブルは必ず両端に同じ名前のタグを付けます。これで床をはがして辿らなくてもケーブルの先がどこに行っているか分かります。 LAN配線ルール３ 「片側ブーツ」でループ防止 ブルーのLANケーブルは片側だけブーツを付けます。 ブーツは通常、混線している場所でジャックの爪が折れるのを防ぐためのものですが、スイッチ側についていると、ポートの間隔が狭いスイッチではキツくてメンテナンスが大変です。 そこで片側だけつけておくことでスイッチ側のメンテナンスも確保でき、かつ、ブーツ側は必ずPCに刺すという運用をすればループを防ぐことも可能です。 LAN配線ルール４ 「ブルーは絶対埋めない」 １のルールの中でブルーのケーブルは埋める必要がありません。ブルーは絶対に床下に埋めないという運用にしてしまいます。 LAN配線ルール５ 「
業務をアウトソーシングした後の社員は何をするの：ナレッジ！？情報共有・・・永遠の課題への挑戦：オルタナティブ・ブログ
ずいぶん前の話だが、ある会社から現在運用しているインフラ系システムのひとつをアウトソーシング（今流行のSaaS)にしたいという引き合いをうけて訪問した。対象のシステムは24H365Dの稼働が求められるため運用が大変で自社の運用管理者を貼り付けておくのが勿体ないというのがきっかけで、システム名を聞く限りどこの会社にもある一般的で共通的なシステムだったので、この意見にさもありなんと同意をして訪問することにした。 当日詳しく話を聞いてみると、このシステムには今でも自社の開発者が数名はり付いて継続的に追加開発やメンテナンスを行っいるとのこと。採用していたプロダクトが独自アーキテクチャーだったことも影響しているのだろうが、ユーザからのきめ細かい要望に対応する為に自社ＳＥをそこに特化させて抱え込んでいたようだ。 ところが本社の企画部門から情報子会社に異動してきたという担当者が声高に叫んでいるのは「単純
ヒトモノカネから「3つのP」へ――ITSMの新資源
企業のビジネスドライバーは「ヒト・モノ・カネ」だと言われてきたが、ITサービスマネジメントの世界ではやや事情が異なる。「3つのP」というリソースが重視されるのだ。 リソースの有効活用と言うけれど 来年（2009年度）の春季から、情報処理技術者試験が大幅に改定される。詳細は情報処理技術者試験センターのサイトで確認できるので、興味のある読者は参照していただきたい。本連載と関係がありそうな変更点は「テクニカルエンジニア（システム管理）」と呼ばれていた試験が新たに「ITサービスマネージャ」という名称の試験に改められ、出題範囲がJIS Q20000、ITILに沿って再編され、よりマネジメント面が重視されることだろう。実は今までこの「テクニカルエンジニア（システム管理）」という試験はあまり人気がなかった。情報処理技術者試験センターの発表によると、平成19年度のテクニカルエンジニア（ネットワーク）の実質
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本のサラリーマンは「35歳定年」でいい――倉貫義人×青野慶久、プログラマーを再定義する | サイボウズ式