運用自動化の基本原則2 「平易化の原則」 /20190524-operation-automation-basic-principle-2
ssmjp 2019/05での発表資料(その2)です。 # 運用自動化の基本原則シリーズ - 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://speakerdeck.com/opelab/
2019-04-18 運用自動化の基本原則1 「引継ぎの原則」 /20190418-operation-automation-basis-principle-1
ssmjp 2019/04 #2での発表資料です。 # 運用自動化の基本原則シリーズ - 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://speakerdeck.com/opelab/20
その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 /20180712-janog42
2018年7月12日、三重県津市で開催のJANOG42ミーティングでの発表資料です。 その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 https://www.janog.gr.jp/meeting/janog42/program/OPE 詳細: https://www.opslab.jp/publish/20180712-janog42.html 以下の方々と議論し、多くの知見を得ることができました。(敬称略) - 長久 勝 (国立情報学研究所) - 今井 祐二 (株式会社富士通研究所) - 畠山 慎平 (エヌ・ティ・ティ・コミュニケーションズ株式会社) (運用設計ラボ合同会社 波田野裕一)
ネットワーク運用自動化のはじめかた
明日からはじめるネットワーク運用自動化 / Let's get started Network Automation from Tomorrow!
Web サービスの信頼性と運用の自動化について / iot40-rrreeeyyy
第40回インターネットと運用技術研究発表会の招待講演で『Web サービスの信頼性と運用の自動化について』というタイトルで発表しました。
正しく運用されているかを評価するのが監視である～ゼロからの運用監視設計（前編）。July Tech Festa 2016
正しく運用されているかを評価するのが監視である～ゼロからの運用監視設計（前編）。July Tech Festa 2016 運用監視の自動化は、複雑化するアプリケーションやサービスに対して効率的かつ確実な運用監視を実現する上で、またコスト削減の意味でも重要な要素になってきています。運用監視の自動化は、どのように考えて実現していけばいいのでしょうか。 7月24日に産業技術大学院大学で行われたイベント「July Tech Festa 2016」のセッション「運用自動化のための Re:ゼロから始める監視設計」は、そのための知見を得る上で大変参考になるものでした。この記事では、そのダイジェストを紹介します。 運用自動化のための Re:ゼロから始める監視設計 前佛雅人氏。 今日の私の話は、業界経験が豊富な方には当たり前すぎる内容かも知れませんが、自分だったら20年前にこれを知りたかったな、ということを
ヌーラボのインフラ運用最前線 2015 〜Terraform による AWS の構成の自動化〜 | 株式会社ヌーラボ(Nulab inc.)
工夫したこと リソースの分離をファイル単位で行い、使い回しができるように配慮した Backlogチーム以外でも利用できるようになるべくAWSリソース単位でファイルを分割しておき組み合わせるだけでリソースが構成できるように配慮しました。 ファイル構成例を記載していますがterraform applyを実行したときに全ファイル読み込んですべてのリソースを作成してくれます。 depends_on設定をしておくと各リソースの依存関係を制御できすべてのリソースをいっきに作成することが可能です。 . ├── config.tf ├── terraform.tfstate ├── terraform.tfstate.backup ├── user_data │ └── api.tpl ├── variables.tf ├── vpc-db-instance.tf ├── vpc-db-subnet-
運用自動化、ここだけは押さえておきたい4つのポイント
運用自動化、ここだけは押さえておきたい4つのポイント：特集：運用自動化ツールで実現する、クラウド時代の運用スタイル（6）（1/2 ページ） 運用自動化が求められる背景から実現法、ツールの選び方、適用法まで、全方位的に解説してきた本特集。今回はこれまでの記事を基に、実現のポイントをシンプルに振り返る。 運用自動化の実現に当たり、何を目指し、何に留意すべきなのか？ テクノロジの進展を受けて、ビジネスとITの距離は年々縮小し、ITのパフォーマンスがビジネスのパフォーマンスを左右する時代になっている。こうした中、市場環境変化が速い中でも着実にビジネス機会を獲得するために、「速くシステムを開発し、迅速にリリースし、エンドユーザーの反応を見て改善／廃棄する」といった一連のフィードバックサイクルをスピーディに回すアプローチが重視されている。 これはSoE（System of Engagement）と呼ば
作業手順書はもういらない！ Puppetにおける自動化の定義書「マニフェスト」の書き方と基礎文法まとめ
連載目次 HTTPサーバーの「マニフェスト」を作ろう 前回の「Puppetのインストールと動作確認、トラブル対処法」では、無事PuppetのインストールをクリアしたR子さん、今回はついに「マニフェスト」（Puppetにおける自動化の定義書）を作成するようです。 K男 お、ちゃんとPuppetのmasterとagentのセットアップができたね！ 感心感心。 R子 もう私、いっぱいいっぱいですぅ。許してくださいよぉ（悲）。 K男 うちの会社ではWebサーバーのチューニングノウハウがあるんだけど、手順書を見てやらなくても自動構築できるようにしたいんだよね。 R子 あ、私も手順書のコピペミスとかで怒られたことあるので、自動化でできると楽ですね～。 K男 では早速、PuppetでWebサーバーを自動構築してみて。あ、うちの部署では基本CentOSだけど、他の部署ではUbuntu使ってるので、Cent
KAIZEN platform Inc. における運用自動化
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
自動障害回復システム 月読の話 - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本泰宇です。短い夏休みから帰ってきました。 今回は cybozu.com のデータセンターで運用を開始した自動障害回復システム「月読」を紹介します。障害にも色々ありますが、今回紹介するのは仮想マシンのホストサーバーの物理障害を検出して、稼働していた仮想マシンを予備のホストに移動する仕組みです。 月読は、データセンター全域に分散したエージェントが協調動作するピア・ツー・ピア (P2P)システムとして作られています。以下分散システムの話題が多数でてきますが、とても難解というわけではないので、分散システムの入門記事としてお楽しみください。 障害にどう対処するか 障害対応の自動化 設計のポイント エージェント間通信 障害の検出と回復 その他の機能 まとめ 障害にどう対処するか 物理障害対策の基本は二重化(多重化)です。アプリケーションサーバーのようにデータを持たないサーバ
Nagiosのアラート情報をSpreadSheetに自動で書き込む - mikedaの日記
『WEB+DB PRESS Vol.75』の『継続的Webサービス改善ガイド』は良かったですね。 その記事に、「毎日、アクセスログを解析した結果をGoogle DocsのSpreadSheetにまとめている」ということが書かれていて、サンプルがgistに公開されていました。 puboo-performance-index.rb へー、SpreadSheetに自動でいろいろまとめるの、なかなか便利そう！ということで自分でもちょっとやってみました。 まずは試し rubyでSpreadSheetを操作するのはgoogle_driveを使うとすごく簡単でした。 #!/home/mikeda/.rbenv/shims/ruby # -*- coding: utf-8 -*- require 'google_drive' session = GoogleDrive.login("<user>@gmai
Chefに挫折したあなたへ。Fabricのすすめ
サーバ設定作業は面倒で間違いを犯しやすいため、Chef/Puppetなどのツールで自動化したいと考えている方は多いと思います。 私もそのような理由からChef(-solo)を習得しようと試行錯誤していました。 その結果、ある程度は動くようになったものの次のような問題があると思いました。 学習に時間がかかる 私は正直、今でもどのファイルに何を書くのかよく分かってないです。 幾分か簡単だと言われるchef-soloでも公式サイトのドキュメントだけではよく理解出来ませんでした。 また、バージョンによる差異なのか目的が異なるのか分かりませんが、ブログ記事を参考にしようとすると十人十色でどれが私に合った手順なのかわかりませんでした。 例え最終的に理解できたとしても、私やあなたが何日もかけて理解できないことはチームのメンバーも理解するのは難しいと思います。 対象サーバにインストールする必要がある Ch
Chefをベースにした日本製の運用自動化ツール「Cloudrop」、エクシードから
データセンターへ投入したサーバの構成やアプリケーションのデプロイツールとしてよく知られているのが「Chef」や「Puppet」といったオープンソースの運用自動化ツールです。特にChefは先日Facebookが採用したことが発表されています。 そのChefをベースにした運用自動化ツール「Cloudrop」がエクシードから発表されました。同社はシステム構築や運用サービスに加え、パブリッククラウドの「Libra」などを提供する日本の企業で、Cloudropはそうした同社の経験を踏まえて作られたもの。 運用自動化ツールは、開発と運用が協力してビジネスゴールを目指す「DevOps」ムーブメントの中で、システムの開発運用を迅速に改善するうえで欠かせないツールとして注目されています。 運用の属人性を排除して自動化、効率化 CloudropはChefをベースにしているため、Chefでの手順書に当たるレシピ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リクルート流SRE インフラ運用がサービスを変える世界
生き残る運用管理者 ～運用自動化を成功させる人、失敗させる人～
宣言型デプロイツールの「正しい」使い方 (考え方編) /20180524-ssmjp-deploy
運用自動化、不都合な真実 // Speaker Deck
Re: 運用に自動化を求めるのは間違っているだろうか
「運用改善」を考える 〜「自動化」を考える前に
