5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年（2023年）4月に明らかにしています。 参考：GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up
面倒くさがりな人に授ける投資術（寄稿・骨しゃぶり） | イーデス
『イーデス』は、複数の企業と提携し情報を提供しており、当サイトを経由して商品への申込みがあった場合には、各企業から報酬を受け取ることがあります。ただし当サイト内のランキングや商品の評価に関して、提携の有無や報酬の有無が影響を及ぼすことはございません。 また当サイトで得た収益は、サイトを訪れる皆様により役立つコンテンツを提供するために、情報の品質向上・ランキング精度の向上等に還元しております。※提携機関一覧 「将来のお金」問題はついてまわるもの。今のうちから、できる範囲での資産運用に関心を持つ人も多いのではないでしょうか。 でも、資産運用に対して「難しそう」とハードルの高さを感じる人は少なくないはず。投資をやってみようと調べてみたものの、口座開設や金融商品の説明などを見て「自分に合ったものを選ぶのなんて無理！」と面倒くささが勝ってしまうなんてことも。 ブログ「本しゃぶり」を運営する骨しゃぶり
リクルートのAWS基盤におけるTerraform運用_実践的な取り組みと組織づくり / HashiCorpVirtualStrategyDay_sudo
2022/04/21_HashiCorp Virtual Strategy Day Japan Vol.2での、須藤の講演資料になります
CloudFormation のテンプレートの検証エラーまたは形式エラーの解決
簡単な説明 受け取ったエラーメッセージに基づいて、次の解決策のいずれかを選択してください。 「JSON が整形式ではありません」 または「YAML が整形式ではありません」エラーについては、「テンプレート構文を検証する」セクションを参照してください。 「テンプレートのリソースブロックにある未解決のリソース依存関係 [XXXXXXXX]」エラーについては、「論理 ID とパラメーターを検証する」セクションを参照してください。 「認識不能なパラメータタイプ: XXXXXXXX」または「無効なテンプレートパラメータプロパティ 「XXXXXXXX」」エラーについては、「パラメータ定義を検証する」セクションを参照してください。 「すべての Condition メンバーは文字列でなければなりません」エラーについては、「Condition が文字列として指定されていることを確認する」セクションを参照して
【書評】IAMの管理・運用に関わる人なら必読！「AWS IAMのマニアックな話」レビュー | DevelopersIO
オペレーション部 江口です。 少し前の話になってしまいましたが、2019年9月に開かれた技術書典7で、「AWS IAMのマニアックな話」という書籍が頒布されました。私も参加して購入、読んでとても良い本だなあ、と思ったのですが、当ブログに書評は投稿していませんでした。 ところが最近、作者の佐々木拓郎氏のTwitterでこんなフリが。 ちなみにサンタさんのクリスマスプレゼントで、クラメソさんがIAMのマニアックな話の書評かいてくれないかなぁと期待しています — Takuro SASAKI＠技術書典-1日目 (@dkfj) December 18, 2019 これには答えざるを得ない。 ということで、この書籍を購入したクラメソ社員として不肖私がレビューさせていただきます。 最初に端的に感想を書いておくと、IAMについて知りたい技術者にとってはまさに必読と言えるでしょう。「マニアックな話」というタ
【失敗と後悔】Flutterアプリ開発 七つの大罪 （と二つの余罪） - Qiita
Flutter Advent Calendar 2019の22日目の記事です。 はじめに 私は今年の5月にウィッシュリスト（やりたいことリスト）を作ったり、共有したりできるアプリをFlutter + Firebaseで作り、リリースしました。この記事では、そのアプリを開発し、約半年間運営する中で見えてきた失敗や後悔をまとめ、七つの大罪として皆様に共有したいと思います。同じ過ちを繰り返す人が一人でも減れば幸いです... 嫉妬の罪：アプリ強制アップデートの仕組みを実装せずにリリースした 罪状 ゲームなどではよくある「アプリの強制アップデート」だが、これを行わず運用している多くのアプリへの〈嫉妬〉から、強制アップデートの仕組みを実装せずバージョン1.0.0をリリースしてしまった 詳細 ゲームアプリを起動して、まずアップデートさせられるという体験を自分がよくしていたんですね。で、これが「面倒だなぁ
ごく普通のエンジニアリング運用チームを強力な SRE チームに変える | Google Cloud 公式ブログ
※この投稿は米国時間 2019 年 10 月 4 日に Google Cloud blog に投稿されたものの抄訳です。 運用チームにエンジニアを絶えず増員しても、お客様の拡大には対処しきれません。Google のサイト信頼性エンジニアリング（SRE）の原則を適用すれば、運用上の問題にソフトウェア エンジニアリングによる解決手法を取り入れることで、うまく対処できます。本稿では、従来のネットワーク エンジニアリングの通例にとらわれず、SRE に転換することで、Google がグローバル ネットワーク運用チームを変革した方法をご紹介します。Google の本番環境ネットワーキング チームがこの問題にどのように取り組んだのかをお読みいただき、ご自分の組織に SRE の原則をどのように取り入れることができるのかを検討してみてください。 スケーリングの限界2011 年、Google の本番環境ネット
祝 CloudWatch Anomaly Detection が GA になりました！ | DevelopersIO
こんにちは 園部です。 オープンプレビュー となっていました CloudWatch Anomaly Detection が GA となりました！ 新規 – Amazon CloudWatch anomaly detection – 異常検出 今回、オープンプレビュー時との差異を中心に、やってみたいと思います！ オープンプレビュー時に関しては、弊社メンバーが記事にしてくれています。 CloudWatchにAnomaly detection(異常検出)が追加されました（Open preview） 最後に、 Anomaly Detection と Outlier Detection について、調べた内容を整理してみます。 CloudWatch Anomaly Detection 異常検出は、選択したメトリクスの履歴値を分析し、毎時、毎日、毎週繰り返される予測可能なパターンを探します。 次に、将来
プロジェクトリスク検知のヒント | DevelopersIO
「プロジェクトのリスクを洗い出しきれていますか？」 この問いに自信を持って「Yes」と即答できる方は以降を確認いただく必要はありません。 「No」もしくは「Yes」と答えるのにちょっと躊躇した方はざっと目を通していただけると、何らかの気づきがあるかもしれません。 ここからは、独立行政法人情報処理推進機構（IPA）が公開している資料を紹介していきたいと思います。 紹介資料 資料名：ITプロジェクトのリスク予防への実践的アプローチ 利用対象者：情報システムの企画、情報システムのプロジェクトマネージャー、PMO、設計者等 特徴：ITプロジェクト目標達成を阻害する事柄をリスクととらえ、リスクとそのリスク発現の要因を中心にすえ、リスクの発現を防ぐために”リスク発現の要因”に対してどのような予防策を打つかその予防策の効果をどのようにとらえるかと”リスク発現の要因”に対してその兆しをどう把握するかの関係
【gitコマンド】いまさらのrevert - Qiita
20190430追記 わかりにくい表現を修正しました。 内容の変更はしていません。 追記ここまで ちょこちょこ使う機会はあったのですが、いまいち使いこなせていなかったrevertについて改めて調べました。 revert とは 既存のコミットを取り消すためのコマンドです。 「取り消したいコミットを打ち消すようなコミットを新しく作成する」という処理によって、既存のコミットを取り消します。 新しくコミットを追加しているだけなので、既存コミットの履歴が消えるわけではありません(コミットログをみると残っています)。 どんな変更があったのかということが(revertしたということも含めて)残るので、リモートにpushされて公開されているコミットに対しても安全に使うことができます。 「既存のコミットを元に戻す」という点について、同じような機能を持つコマンドにresetが存在します。 resetコマンドは
サル先生のGit入門
ブランチ ブランチとは ブランチの運用 ブランチの切り替え ブランチの統合 トピックブランチと統合ブランチでの運用例 チュートリアル1 ブランチを使ってみよう！ 0. 前準備 1. ブランチを作成する 2. ブランチを切り替える 3. ブランチをマージする 4. ブランチを削除する 5. 並行で作業する 6. マージでの衝突を解決する 7. rebaseでマージする リモートリポジトリ pull fetch push タグ タグ チュートリアル2 タグを使ってみよう！ 0. 前準備 1. 軽量タグを追加する 2. 注釈付きタグを追加する 3. タグを削除する コミットの書き換え 直前のコミットを修正する 過去のコミットを打ち消す コミットを捨てる コミットを抜き取る コミットの履歴を書き換える ブランチ上のコミットを一つにまとめてマージする チュートリアル3 コミットを書き換えよう！ 1.
Gitを実践的に使うために参考にすべき記事20選
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit（GitHub）をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです！ ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と５つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
git-svnを利用した運用を考える - Qiita
最近、諸事情あってsubversionからgitへプロジェクトの半ばでバージョン管理を変更しました。その際にちょっと変わった形でgit-svnの運用を行う事になったのでやりかたに関して簡単にログを残しておきます。 プロジェクトを取り巻く事情 今まではSubversion(仮にメインとします)を用いた運用を行っていたのですが、気軽にtrunkに対してコミットする事が出来ない事情がありました。では、メインSubversion上にbranchをたてればいいじゃんという話になるのですが、ブランチすら気軽に切る事が出来ない状態でした。その上、メインのSubversionにコミットすることが可能なのはコミッターだけとなっておりコミッターの負担が増えつつありました。 今までの運用 今まではメインSubversionとは別に 同期しないSubversion(仮にローカルとします)を別途立てて、なんと手動で
git-svnを使うときのベストプラクティス - Life goes on
いつもの事ですが、タイトルは釣り。 現在のプロジェクトにアサインされてから、VCSがsvnに逆戻りしてしまったのでかれこれ5ヶ月近くgit-svnを使用してます。初めの頃に2~3回程checkoutしなおすレベルの失敗があったりしましたが、ここの所はそれほど問題無く運用してます。 gitとsvnでもう根本の仕組みから全然違うんで、ある程度しょうがないのですが、ちょっとばかり気をつけないとハマる可能性があるので、その点について語ります。 svnがremoteになってるブランチは 絶対 に直接コミットなどしない 自分の中ではこれが鉄則になってます。例えば普通のsvnの構成だと、trunkがgitのmasterブランチになりますが、何かの修正するって時にはどんだけ軽い修正とかでも絶対にトピックブランチを作ってます。 原則として、masterブランチ(や、他のsvnで作ってあるブランチ)には、gi
git運用フローの選び方 - Qiita
会社のブログに書こうかと思ったけれど、ちゃんと調べられてないのでメモがてらQiitaに書いておく。 本稿ではチーム開発においてフローを選ぶ際のポイントについて述べる。 TL;DR 運用フローは次のポイントに注意して選ぶと良い。 リリースサイクルの長短（長く計画的 or 短くアドホック） メンテするバージョンの数（1つ or 多数） 並行して開発するバージョンの数（1つ or 複数） フロー リリース メンテ 開発 github-flow 短 1つ 複数 git-flow 中 1つ 1つ stable trunk 中〜長 1つ 複数 mainline 中〜長 複数 1つ git運用フローとは VCS一般には「ブランチ戦略」とも言われる。 ここでは以下のように定義する。 git(VCS)を使う上で、どのブランチで作業し、 どのタイミングでブランチを分け、マージするかを定めたルールのこと。 よく
Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（後編） | DevelopersIO
Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（後編） はじめに 本記事は、全９回の SRE 社内勉強会のアウトプットとして執筆したブログの後編となります。 前編をお読みでない読者の方がおられましたら、是非前編もご一読ください。 ５章 トイル（労苦）の撲滅 「通常運用中のシステムに人手が必要なら、それはバグだ。通常の定義は、システムの成長と共に変化する。」 トイルを減らしサービスをスケールさせる作業こそが SRE における「エンジニアリング」である点を説明しています。聞き慣れない言葉ですが、トイルとは何でしょうか？ここでは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向をもつものと述べられています。例えば
Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（前編） | DevelopersIO
Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（前編） はじめに 筆者が入社した直後 2017/4 吉日に、弊社 IT 推進室長の植木（当時、オペレーションチームの部長）が「SRE 勉強会するよ」という発言に端を欲し各自英語版を翻訳した資料を持ち寄り全９回の SRE 勉強会が 2017/5/11 より開始されました。本勉強会のアウトプットとして、本ブログを執筆します。 なお、本ブログ記事はSRE 勉強会の対象となった第１章〜第９章まで（第２章を除く）を要約した形でお届けし、SRE を知るきっかけとなれば幸いであると考えております。そのため、興味をお持ち頂いた読者の方々は下記のオンライン本もしくは翻訳本のいずれかをお手に取って頂き、その詳細について学んで頂ければと思います。 SRE とは 誤解を恐れずにざっくり説明すると、以下になります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
もしSIerのエンジニアがSRE本を読んだら
