タグ

関連タグで絞り込む (23)

タグの絞り込みを解除

devopsに関するnegima1976のブックマーク (14)

  • Infrastructure as Code の静的テスト戦略 #DevOpsDaysTokyo / DevOpsDays Tokyo 2021


    DevOpsDays Tokyo 2021 で使用したスライドです。 Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか？ 本セッションでは、実際の環境を構築する﹁前﹂に、IaC のコード自体に対してテストを行う手法について解説します。 ご存知の通り Infrastructure as Code (IaC) は、インフラをコードで定義することを通し、アプリケーション開発のベストプラクティスをインフラ領域にも輸入しようとする方法論です。IaC の考え方は近年急速に普及し、開発フローの一部として種々の IaC ツールを利用することは半ば常識のような状態にあります。 しかし同時に、IaC は銀の弾丸ではありません。特に組織的な導入を考えようとすると、得てして﹁なぜか上手くいかない﹂﹁余計に運用が辛くなってしま
    Infrastructure as Code の静的テスト戦略 #DevOpsDaysTokyo / DevOpsDays Tokyo 2021

  • 祝Jenkins15周年、「Developer Productivity Engineering」に貢献してきたことを誇りに思うと川口氏。DevOps World / Jenkins World 2019 Sanfrancisco


    祝Jenkins15周年、﹁Developer Productivity Engineering﹂に貢献してきたことを誇りに思うと川口氏。DevOps World / Jenkins World 2019 Sanfrancisco 8月12日から15日にかけて、サンフランシスコのモスコーニセンターで﹁DevOps World / Jenkins World 2019 Sanfrancisco﹂が開催されました。 今年はJenkinsの15周年にあたります。基調講演にはJenkins開発者である川口耕介が登壇。Jenkins開発当時のことを振り返りつつ、会場の参加者とともに15周年を祝いました。 本記事では、その内容をダイジェストで紹介します︵講演は英語で行われており、本記事ではその内容の一部を翻訳して紹介しています︶。 Jenkinsの開発当初を振り返る Jenkinsの開発者 川口耕介氏
    祝Jenkins15周年、「Developer Productivity Engineering」に貢献してきたことを誇りに思うと川口氏。DevOps World / Jenkins World 2019 Sanfrancisco

  • レガシーサーバーを現代の技術で再構築する/builderscon2019

    https://builderscon.io/builderscon/tokyo/2019/session/6509eeb6-356b-4f77-b709-823f138da640

    レガシーサーバーを現代の技術で再構築する/builderscon2019

  • 技術なきマネジメントの衰退とその対策 - メソッド屋のブログ


    今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は﹁技術力﹂の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に3年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、﹁技術
    技術なきマネジメントの衰退とその対策 - メソッド屋のブログ

  • 闇のDevOps DevOpsと業績評価 – ところてん – Medium

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

    闇のDevOps DevOpsと業績評価 – ところてん – Medium

  • Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ

    Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ 「Site Reliability Engineering」（SRE）とは、GoogleのシニアVPであるBen Treynor氏が提唱した、高い信頼性や性能を発揮するシステムインフラを実現し、改善していくアプローチのひとつです。 これまでの運用チームやインフラチームによる運用や改善とSREが異なるのは、SREでは積極的にコードを書き、ソフトウェアによって目的の達成を目指している点にあるといえます。 Googleが公開しているSREのWebサイトでは、SREを次のように説明しています。 Like traditional operations groups, we keep important, revenue-critical syst

    Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ

  • はてなでの サービス信頼性向上のための 取り組み事例

    SRE Tech Talks ( http://connpass.com/event/34825/ ) でお話した際の資料です

    はてなでの サービス信頼性向上のための 取り組み事例

  • DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い

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

    DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い

  • 突撃！隣のDevOps パート1【Wantedly編】 | DevelopersIO


    はじめに こんにちは！おおはしりきたけです。今回は、突撃！隣の開発環境ではなく、突撃！隣のDevOpsというタイトルで、イケてる開発会社さんのDevOpsについてインタビューさせてもらいました。パート1として突撃！隣の開発環境のパート1でも紹介させて頂いた、WantedlyさんにDevOpsをどのようにやっているのかを伺ってきました！ 突撃！隣のDevOpsとは 突撃！隣の開発環境では各会社さんの開発の方法や、どのような体制で開発をしているのかという形で、﹁開発﹂に焦点を当てたインタビューをさせていただいていました。実際、ソフトウェアサービスと言うのはリリースしてからがスタートであり、日々の改善活動や安定運用を行うため、開発︵Development︶と運用︵Operations︶が協力し合いながらビジネス要求に対し、早くかつ柔軟に対応していくかが求められます。そこで、突撃！隣のDevOps
    突撃！隣のDevOps パート1【Wantedly編】 | DevelopersIO

  • Ansible、シスコやArista、Juniperなどのネットワーク機器に対応。ネットワークも含めた構成自動化が可能に


    Ansible、シスコやArista、Juniperなどのネットワーク機器に対応。ネットワークも含めた構成自動化が可能に Ansibleはエージェント不要でサーバを構成できるのが最大の特長です。昨年10月にRed Hatが買収し、先月にはメジャーバージョンアップとなる﹁Ansibe 2.0﹂が発表されたばかり。 Ansible 2.0では、構文の強化によってより高度な処理を記述しやすくし、実行速度を高速化するオプションなどが追加されました。 今回の機能拡張では、サーバだけでなく複数のベンダのネットワーク機器に対してもAnsibleから統一的に構成を行えるようになり、システム構成についてソフトウェアとネットワークを統合的に自動化できるようになりました。 現時点でAnsibleがサポートするネットワーク機器は以下となっています。 Arista Networks ‥ Arista EOS Cis
    Ansible、シスコやArista、Juniperなどのネットワーク機器に対応。ネットワークも含めた構成自動化が可能に

  • 【お知らせ】アジャイル/DevOps/クラウド関連支援サービスを開業しました


    みなさまこんにちは。@ryuzeeです。 昨年10月にAmazon Web Servicesを退職して以来、久々にのんびりとした時間を過ごし、ムリを言って期間のコミットのない仕事をさせていただいておりましたが、このたび正式に支援サービスを開始することにいたしましたのでご報告です。 主なご支援内容は以下のとおりですので、ご興味のある方はお知らせいただければ幸いです。詳細についてはこちらをあわせてご参照ください。よろしくお願いします！ 以下FAQです。 どんな領域の支援ができますか？ 支援の領域は主に4つです。順にアジャイルコーチングとトレーニング、DevOps実践支援、Cloud Architecting支援、そして技術顧問・執筆・講演です。 アジャイル関連の支援ってどんなものですか？ オンサイトを中心にアジャイル開発での企画〜開発まで全工程を支援します。プロジェクト立ち上げに際しての集合研
    【お知らせ】アジャイル/DevOps/クラウド関連支援サービスを開業しました

  • 【資料公開】強いチームの作り方 | Ryuzee.com


    2015年11月10日に某社の社内勉強会で、﹁強いチームの作り方﹂というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに﹁インフラ自動化しないといけない﹂とか﹁ツール使って効率化﹂みたいな話を頻繁に聞きます。 が、端的にいえば、﹁実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである﹂というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
    【資料公開】強いチームの作り方 | Ryuzee.com

  • Fluentd update 2014 - Qiita


    毎年恒例1年のまとめ記事です．2014年はFluentdの飛躍の年でもあったので，エコシステム周りも含め色々と紹介したいと思います． 2014年は0.10.43から始まり，v0.10の最新版は0.10.57，v0.12が開発版としてpre2までリリースされています．v0.12に関しては13日，v1を含めた来年の開発に関しては25日に書く予定です． Fluentd本体 すべてを列挙するのは難しいので，すべてを見たい方はChangeLogを参照してください．ここでは特に運用やプラグイン周りで有用なものをピックアップします． プラグイン毎のlog_levelオプション (0.10.43) グローバルなレベルとは別に，各プラグイン毎にログレベルを設定出来る機能です．詳細は以前書いたFluentdのロギングを参照してください． sigdump (0.10.43) sigdumpが同梱されるようになり
    Fluentd update 2014 - Qiita

  • ディレクターやエンジニアが運用エンジニアにインフラの相談をする際に持って来て欲しい5つのこと - blog.nomadscafe.jp


    新しいWebサービスを開始する際や、既存サービスに変更を加える際に、サーバを何台確保するか、ストレージやAPIといった共有リソースを使用して良いか、ディレクターやアプリケーションエンジニアの方に訪ねられることがありますが︵というかそれが仕事ですね︶、その際相談のためにどんな情報を持って来て欲しいか書いてみます。人間同様にサーバやネットワークリソースも有限なので、無駄にならない最適なサーバ台数を割り出したり、増強が必要かどうかを判断して、会社のビジネスを効率よく進めていくことが重要です。 人によっては以下に書いてあることが、非常に緩く感じでしまうこともあるかもしれません。これはWebサービスを早く立ち上げて、柔軟に運用していくことができる環境ならではだと思います。それでも出して欲しいモノはいくつかあります 企画書 どんなサービスであるか説明できる企画書があるといいでしょう。ないわけはないと信
    negima1976
    negima1976 2011/07/15
    本気度合い(熱意)大事だわ…
    リンク
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.