タグ

DevOpsに関するSWIMATH2のブックマーク (14)

  • [書評]「New Relic 実践入門 監視からオブザーバビリティへの変革」は可観測性を学び実践するための一冊 | DevelopersIO

    こんにちは、臼田です。 みなさん、よりよい運用してますか?(挨拶 今回は2021年9月15日に発売された書籍「New Relic 実践入門 監視からオブザーバビリティへの変革」の書評です。オブザーバビリティ(可観測性)について概念的にも実践的にもわかりやすい図とともに理解でき、特にNew Relicを活用して、単純な監視ではない、ビジネスに貢献するための運用の実践ができる一冊でした。 この記事ではこの書籍を読んで感じた、どんな人に向いているか、特に良かったところなどを書いていきます。 どんな人に向いているか 一言でいうと、「これからNew Relicを触る人、あるいは触り始めた人が活用できる書籍」です。「New Relic実践入門」というタイトルそのままですね。 逆に言えば、関連するオブザーバビリティについて理解を深めたい、あるいはNew Relicに限らない監視や運用の考え方を学びたいだ

    [書評]「New Relic 実践入門 監視からオブザーバビリティへの変革」は可観測性を学び実践するための一冊 | DevelopersIO
    SWIMATH2
    SWIMATH2 2021/10/24
    うちでは datadog 使ってるけど、参考になる部分も多そう
  • 0から始めるNode.jsパフォーマンスチューニング

    近年の Node.js は API のサーバとしてはもちろん、Nuxt.js や Next.js といった SSR や BFF などフロントエンドのためのバックエンド言語としての人気が高まっています。 フロントエンドエンジニアがコンテキストスイッチ少なくバックエンドの整備ができることは非常に大きな利点です。 ですが、フロントエンド(ブラウザ側)とバックエンド(サーバ側)ではパフォーマンスチューニングで見るべき点が大きく違います。 しかし Node.js アプリケーションのパフォーマンスイシューの見つけ方などがまとまっている資料は少ないです。 そこで、記事ではフロントエンドエンジニアが Node.js でパフォーマンスイシューを見つけ、改善するため自分が普段パフォーマンスチューニングを依頼されているときにみている基礎的なポイトをまとめていきます。 1. 計測ステップlink Node.js

    0から始めるNode.jsパフォーマンスチューニング
  • DevOpsカルチャーのKPI - kawasima

    このツールは、全体的な傾向を把握するためのもので、意図的に不正確な指標になっている。そのため個人の仕事のパフォーマンスを評価するために使ってはいけない。

    DevOpsカルチャーのKPI - kawasima
    SWIMATH2
    SWIMATH2 2021/05/22
    DevOps カルチャーにかぎらず、開発一般に活用できそうな指標で良かった。開発チームの目標って定量化しづらいんでこういうの使うのよさそう
  • Slack ワークフロー × GitHub Actions で何時でも誰でも楽なステージングデプロイを実現する - Pepabo Tech Portal

    こんにちは! 先日最終話が放映された Dr.STONE 2 期が始まった頃、先が気になりすぎて漫画版を大人買いした CTO室 鹿児島オフィスチームのよしこ @yoshikouki です。これぞ社会人の嗜みだなと感慨深くなった30歳の春。 今回は私が運用・開発に携わっているホスティング事業部で Slack ワークフローと GitHub Actions を組み合わせて業務を改善しましたので紹介したいと思います。改善は、サービスの番環境に近いステージング環境へのデプロイ作業を Slack 上で行えるようにして、デプロイのための環境構築を不要にしたことに加えて必要なステップを 1 つだけにすることができました。 これまでステージングデプロイの問題点 環境構築についての比較 改善前 改善後 デプロイフローについての比較 改善前 改善後 どのようにして改善したのか 実際の操作画面と流れ 実装方法

    Slack ワークフロー × GitHub Actions で何時でも誰でも楽なステージングデプロイを実現する - Pepabo Tech Portal
    SWIMATH2
    SWIMATH2 2021/04/14
    よさみ
  • 障害対応時にまずはissueを作ると良い - そーだいなるらくがき帳

    先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。 classmethod.jp 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。 今回のスコープの外 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSのボトルネックの探し方などの話はしません。 まずissueを作ると良い 題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 g

    障害対応時にまずはissueを作ると良い - そーだいなるらくがき帳
  • DevOps の能力  |  Cloud アーキテクチャ センター  |  Google Cloud

    デジタル トランスフォーメーションを加速 お客様がデジタル トランスフォーメーションに乗り出したばかりでも、あるいはすでに進めている場合でも、Google Cloud は困難な課題の解決を支援します。

    DevOps の能力  |  Cloud アーキテクチャ センター  |  Google Cloud
    SWIMATH2
    SWIMATH2 2019/10/27
    こんなgoogle公式のまとめあるんだ
  • アジャイル開発ガイ.pptx - Microsoft PowerPoint Online

    SWIMATH2
    SWIMATH2 2018/02/07
    めっちゃ良い、最高
  • DevOpsに関する12のアンチパターン

    みなさんこんにちは。@ryuzeeです。 DevOpsGuysというサイトのTwelve DevOps Anti-Patternsという記事が秀逸です。 作者の方に許可を頂き翻訳しましたので公開します。 原文も軽妙なタッチで読みやすいと思いますのでぜひご参照ください。 また文で様々なスライドや資料へのリンクがありますので、そちらも見ていただくと理解が深まるんじゃないかと思います! えっとDevOpsを始めたいのかな?おっけー。ただ始める前に、やってはいけないいくつかのことについて見ておこう。 古き良き時代には単に「良くないアイデア」って呼んでいたんだけど、外交やポリティカル・コレクトネス運動の結果、ブレストやアイデアシャワーをして、最近は「アンチパターン」と呼ばれるようになった。 パターンが絶対的に正しいのであれば、すなわち「アンチパターン」は間違いということになる。そして間違いを避ける

    DevOpsに関する12のアンチパターン
  • Scrum / DevOps の導入を加速するグローバルマインドセット ~8つの習慣 その1 ~ - メソッド屋のブログ

    クロスカルチャーの専門家Rochelle Koppさんと一緒に考案した 新技術の導入を加速させるための「8つの習慣」をまとめ上げた。この習慣を習得することで、米国と同じようなスピードで新しいことに対応したり、生産的になることができる。今回はその一つ目の習慣について解説してみた。 今回、日最大級のアジャイル開発のイベントの一つである Scrum Gathering Tokyo で先のRochelle さんと一緒に「8つの習慣」を初めて発表させていただいた。 2017.scrumgatheringtokyo.org 「8つの習慣」は日での Agile / DevOps をはじめとする最新技術やプロセスの導入を米国並みのスピードにすることを目指している。Agile や DevOps を開発した人は西洋の人なので、西洋文化の上に成り立っている。だから、日文化の上でそれらを使うと、どうもうま

    Scrum / DevOps の導入を加速するグローバルマインドセット ~8つの習慣 その1 ~ - メソッド屋のブログ
  • DevOps スタータキットの公開 - メソッド屋のブログ

    DevOps の概要、プラクティス、そしてそれに関するリソースを整理して自ら学習しやすいようにしてみました。DevOps の考え方、プラクティス毎に、ビデオとそこで使っているPPTを公開しますのでお楽しみください。 channel9.msdn.com docs.com docs.com 1. DevOps の歴史 DevOps を学ぶときに、海外と比べると日の商習慣が異なるので、向こうで話されているDevOps の概要を聞いてもピンと来ないかもしれません。そこで、DevOps の歴史を7分程度で学べる動画を作成しました。 これで、DevOps が生まれきた背景が学べると思います。 docs.com 2. DevOps の概要 DevOps の歴史を知るとと、DevOps の概要がよりわかりやすいかもしれません。次のビデオをご覧ください。 docs.com DevOps プラクティス ビデ

    DevOps スタータキットの公開 - メソッド屋のブログ
    SWIMATH2
    SWIMATH2 2018/02/07
    凄い情報量
  • DevOpsとは何か? そのツールと組織文化、アジャイルとの違い

    両氏はこのプレゼンテーションの中で、それぞれの役割の違いから対立することの多い開発者(以下、Dev)と運用者(以下、Ops)の対立構造を次のように示した。 Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割は“システムの安定稼働”である。そのため、Devが新しい機能を追加したくても、Opsはシステムの安定稼働のために変更を加えたがらない、という対立構造が作られてしまっていた。 しかしDevとOpsのそれぞれのミッションは(DevOpsの概念と同じく)、どちらも「システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」ことである。そのミッションを達成するための手段が、上記のとおりDevは“システムに新しい機能を追加する”であり、Opsは“システムの安定稼働”なのである。つまり、同じ「ミッション」を掲げている

    DevOpsとは何か? そのツールと組織文化、アジャイルとの違い
    SWIMATH2
    SWIMATH2 2018/02/07
    よくまとまってる感じする
  • 衝撃的な効率性~最高の DevOps チームは「知っている事」で構成されていた~ - メソッド屋のブログ

    今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って物を見てみたかったのだ。 だから、今回Samにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日で行っ

    衝撃的な効率性~最高の DevOps チームは「知っている事」で構成されていた~ - メソッド屋のブログ
    SWIMATH2
    SWIMATH2 2018/02/07
    教科書通りのことをやるのって難しいんだよなあ
  • 闇のDevOps DevOpsと業績評価 – ところてん – Medium

    ここから、DevとOpsが協力すればより効率的になる=DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか? ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート(設置作業員、サポートセンタ)には、大量の人員が必要になってきます。 したがって、組織を研究

    闇のDevOps DevOpsと業績評価 – ところてん – Medium
    SWIMATH2
    SWIMATH2 2017/09/04
    DevOpsの理念がとても分かりやすい。ところどころ日本企業の闇が漏れていてつらくなる
  • 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

    Communications and cooperation between development and operations isn't optional, it's mandatory. Flickr takes the idea of "release early, release often" to an extreme - on a normal day there are 10 full deployments of the site to our servers. This session discusses why this rate of change works so well, and the culture and technology needed to make it possible.Read less

    10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
    SWIMATH2
    SWIMATH2 2017/09/04
    DevOpsの始まり的なスライドらしい。技術的な話と生活上の話があってエモい
  • 1