ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
運用設計における設計項目の体系化 / 20240207-ssmjp-operation-design-items
ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
システムの運用設計とは？種類やメリット、運用設計のポイントを解説
社内のITシステムやネットワークを安定的に稼働させ、日々の業務を滞りなく行うためには、システム運用設計が必要です。とはいえ、『運用設計』とひとことで言っても、何をやれば良いのか、そもそもなぜ運用設計を行うべきなのかなどが分からず、手がついていないといったこともあるでしょう。そこで、本記事ではシステム運用設計の種類や行う理由、運用設計の流れやポイントについて解説します。 運用設計とは 運用設計とは、システムを安定して運用していけるよう、日常的に行うべき業務や運用ルール・運用方法、障害が起こったときの対応などをあらかじめ決めておくことです。システムが正常に動いているかをどう監視するのか、定期的にチェックする方法、インシデントを検知したときどんな手順で対処するか、どの部署や外部業者に連絡するか、などが該当します。 全体の流れを見ながら運用設計を進めることで、システムの定常的な安定稼働を助けます。
第３回：運用設計の考え方―運用管理対象をどういう視点で管理するのか？運用要件から落とし込むときのポイント | クラウド導入・システム運用ならアールワークスへ
Managed Service Column ＜システム運用コラム＞第３回：運用設計の考え方―運用管理対象をどういう視点で管理するのか？運用要件から落とし込むときのポイント システムのクラウド移行が加速する中、「クラウドサービスを活用しているが、クラウド毎に個別に監視・運用をしているため、運用が煩雑化している。どうすればよいか？」「オンプレミスとクラウドを併用することになり、運用管理体制を見直したい」といったお声をいただくことも多くなりました。 システムは構築して終わりではなく、安定稼働するための運用が重要です。そして、システム運用の品質を担保しながら効率を上げていくためには、運用設計が必要となります。 この連載では、運用設計の考え方やの取り組みについて、事例も交えて紹介します（全12回）。 はじめに 前回のコラムでは、システムの目的（あるべき姿）を維持するために監視・管理する、システム構
たとえ障害の根本原因であっても“変化”を起こせることが大事 DevOps実現のための6つの方法と4つの文化
DevとOpsの対立 川口恭伸氏（以下、川口）：2009年からDevOpsが出てきます。 DevOpsの話、これは源流の「10+ Deploys per Day」というものがあって、ビデオを見ながら私が書き起こしたので紹介したいんですけれど。2009年に何が起きたか、どんな話だったかです。 「10+ Deploys per Day」は、1日に10回デプロイするというタイトルです。これはたぶん彼らの中で使っていたクラウドの話だと思うんですが、効率的なデータセンターを使い、デベロッパーと運用者が協調しながらガンガン10回デプロイできるようにするみたいな。それでも品質が壊れないようにするみたいな話が出ていて。 その時に、「じゃあどうやってみなさんは協調するのか」という技術論や文化の話が非常におもしろくて、DevOpsに興味がない方もぜひこれは1回見てもらいたい。特に、AWSとかインフラとかに近い
リクルートのAWS基盤におけるTerraform運用_実践的な取り組みと組織づくり / HashiCorpVirtualStrategyDay_sudo
2022/04/21_HashiCorp Virtual Strategy Day Japan Vol.2での、須藤の講演資料になります
DevOpsトポロジー
みなさんこんにちは。@ryuzeeです。 2021年12月1日に発売した『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』ですが、おかげさまで多くの方に読んでいただき感謝しています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社：日本能率協会マネジメントセンター発売日：2021-12-01単行本：280ページISBN-13：9784820729631ASIN：4820729632 今日はこの「チームトポロジー」の元となったDevOpsトポロジーについて紹介します。 このアイデアは2013年に著者の1人であるマシュー・スケルトンが自身のブログに書いた記事をまとめたものです。 2013年頃といえばDevOpsが流行しはじめた時期だと思いますが、こ
運用の考え方は「システム管理」から「サービス管理」へ ITIL4で変わってきた、運用者に求められること
インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『運用改善の教科書』の著者である近藤氏が登壇。続いて、ITIL4の登場に伴う運用の考え方の変化と、昨今の運用に求められていることを紹介します。前回はこちらから。 2019年頃に起きた運用の変化 近藤誠司氏（以下、近藤）：みなさん運用をやっている方が多いということで、ご存知のITIL（Information Technology Infrastructure Library）のv3、シラバス2011をベースにしたものを貼っています。いろいろとプロセスや機能などがあって、分類がありました。 シラバス2011、ITIL v3の時点では、基本的にはサービスストラテジが戦略を練る、サービスデザインは設計するというところです。トランジションは、設計したものを作って移行する
Terraformerとしてコードを書いて思うこと | フューチャー技術ブログ
こんにちは。TIGの伊藤です。この記事は秋のブログ週間2021の3日目です。 はじめに私は普段会社でクラウドをまたいでTerraformを日々書いたり、メンバーに教えたりしています。もはや俗に言うプログラミング言語を書かずにここまで全振りしてきたくらいなので、比較的自信を持ってコードを書いて仕事をしています。 特にここ最近はほぼ1からコード設計をして運用まで持っていくこともあり、「より腐りにくい、より息の長いコード」というものを考えるようになりました。Terraformだからこその「定期メンテを簡易にするためには」「より簡単に変更するためには」をひたすら突き詰めていった結果、アツい気持ちが生まれ、今回は筆を取っています。 そんな私のアツい気持ちをしたためた今回の記事ですが、可能な限り例も添えつつ、いくつか解説できればと思います。公式にも実は載っているような内容もあったりしますが、日本語の記
「運用組織」の考え方と設計 〜 運用組織論 2021 / 20210310-ssmjp-operation-organization
ssmjp ssmonline #8 "第三回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/206074/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
[レポート] オペレーション、監視(Monitoring)、可観測性(Observability)… AmazonのCTOはAWS re:Invent 2020のキーノートでどう語ったか？ キーワードを拾ってみた #reinvent | DevelopersIO
昨年12/18（日本時間では12/19）、AWS re:Invent 2020におけるのDr. Werner Vogels（ヴァーナー・ボーガス氏）のキーノートは皆さんご覧になられたでしょうか。 氏のキーノートセッションは毎回恒例ですが、例年だと開発環境や実行環境・AWSインフラについての話にフォーカスがあたっている印象でした。その中で「Everything fail, all the time」や「You build it, You run it」のような名言・格言が語られてきました。 ところが今回は「Developer Keynote」と銘打った上で、よりオペレーション段階の話に長く時間が割かれました。MLやインフラに特化したキーノートが別にあったことも要因のひとつでしょう。 どんなことが語られたのか？ 個人的に気になったキーワードをひろってみました。 なお記事中の訳は基本的にぼくの解
![[レポート] オペレーション、監視(Monitoring)、可観測性(Observability)… AmazonのCTOはAWS re:Invent 2020のキーノートでどう語ったか？ キーワードを拾ってみた #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/6ff0ae3d489a3ff18121e329779daf6be5562ed5/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F01%2F202012-report-reinvent-keynote-observability-eyecatch.jpg)
SRE実践の手引 ─ 信頼性をどう制御するか？ から始める、現実的な指標と目標の設計と計測 - エンジニアHub｜Webエンジニアのキャリアを考える！
SRE実践の手引 ─ 信頼性をどう制御するか？ から始める、現実的な指標と目標の設計と計測 SREの役割には、信頼性、SLIとSLO、エラーバジェット、トイル、ソフトウェアエンジニアリングといった複数のキーワードが存在するがゆえ、なかなかうまく実践できない、という声もあります。本稿では、難しく見られがちなSREの内実を、「信頼性の制御」というコンセプトを軸に整理し、小さく始める一歩を坪内佑樹（ゆううき）さんが解説します。 こんにちは。SREの研究者をやっているゆううき（@yuuk1t）です。 SRE（Site Reliability Engineering）は、従来のオペレーションエンジニア、システム管理者（sysadmin）と呼ばれる人々が担っていた技術領域の新しい形です。Googleによって提唱され、日本国内でも2015年ごろからWebコンテンツ事業者のコミュニティを中心に広く知られる
デブサミ2020で「礼節から育てるチームの健康と信頼性」という話をしました #devsumi #devsumic | DevelopersIO
事業開発部の塩谷 (@kwappa) です。 2020年2月13, 14日、目黒雅叙園でDevelopers Summit 2020（通称「デブサミ」）が開催されています。その初日である2/13、 13-C-6 という枠をいただいて「礼節から育てるチームの健康と信頼性」という話をしました。 スライド セッション 昨年10月から継続してしゃべっている、チーム・心理的安全性・礼節についての総集編を目指してつくりました。過去のセッションから大きく変えてはいませんが、登壇を重ねるたびに自分でも理解が深まったように思います。 公式サイトの事前予約では「満席」の表示があり、実際のセッションもちらほら立ち見の方が出るぐらいの入場がありました。公募に通ったのも不思議なぐらいのふわっとしたタイトルでしたが、たくさんの方に聞いていてだけてとても光栄ですし、話し甲斐もありました。 聴いてくださったかたのツイート
SRE の原則に沿ったトイルの洗い出しとトラッキング | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 2 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 作業効率を検証するために Google のサイト信頼性エンジニア（SRE）が使用している主な測定指標の一つが、日々の時間の使い方です。長期間のエンジニアリング プロジェクトのために時間を確保する必要がありますが、エンジニアには Google のサービスを稼働し続ける責任もあり、そこにも手作業が生じることがあります。Google の SRE は、いわゆる「トイル」に費やされる時間を勤務時間の 50% 未満にすることを目指しています。では、トイルとは何でしょうか。トイルに邪魔されずに開発スピードを維持するには何をすべきでしょうか。本稿ではこれらの問いについて見ていきます。 まずトイルの定義ですが、『Site Reliability Engineering』の第 5 章には次の
SRE for single-tiered software applications | Google Cloud Blog
In cloud operations, we often hear about the benefits of microservices over monolithic architecture. Indeed, microservices help manage hardware being abstracted away and push developers towards resilient, distributed designs. However, many enterprises still have monolithic architectures which they need to maintain. For this post, we’ll use Wikipedia’s definition of a monolith: “A single-tiered sof
SRE チームの評価に役立つレベル別チェック リスト | Google Cloud 公式ブログ
※この投稿は米国時間 2019 年 1 月 26 日に Google Cloud blog に投稿されたものの抄訳です。 このたび、『The Site Reliability Workbook』がウェブサイトで閲覧できるようになりました。Google で生まれ、他の企業にも広まりつつある Site Reliability Engineering（SRE）は、運用上の問題をソフトウェア的に解決するためのエンジニアリングであり、Google におけるエンジニアリングの本質的な部分を占めています。 SRE は考え方であり、一連のプラクティスやメトリクスであり、システムの信頼性を保証するための処方箋でもあります。SRE モデルを構築すれば、サービスの信頼性が向上し、運用コストが下がり、人間が行う作業の価値が高くなって、サービスとチームの双方で大きなメリットが得られます。上述の新しいワークブックは、
Google - Site Reliability Engineering
Introduction Written by Benjamin Treynor Sloss6 Edited by Betsy Beyer Hope is not a strategy. Traditional SRE saying It is a truth universally acknowledged that systems do not run themselves. How, then, should a system—particularly a complex computing system that operates at a large scale—be run? The Sysadmin Approach to Service Management Historically, companies have employed systems administrato
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
運用設計とは？必要項目や設計の流れ・ポイントをイチから解説！
監視論 ～SREと次世代MSP～
2018-London/Tuesday/Breakout Sessions/Throne, Stephen, Getting Started with Site Reliability Engineering.pdf at master · devopsenterprise/2018-London
