1,800円以上の注文で送料無料

DevOps教科書 の商品レビュー

3.4

5件のお客様レビュー

  1. 5つ

    0

  2. 4つ

    2

  3. 3つ

    3

  4. 2つ

    0

  5. 1つ

    0

レビューを投稿

2021/09/02

前半のdevopsの原理原則は、どの本よりもしっくりきた説明だったように思います。 後半は私には難解でした。いつどの場面で役に立つ知識なのか、自身の業務で役立つイメージできず、読むこと自体断念しました。 また古い本なので仕方が無いですが、出てくるツールは現在のベストプラクティスか...

前半のdevopsの原理原則は、どの本よりもしっくりきた説明だったように思います。 後半は私には難解でした。いつどの場面で役に立つ知識なのか、自身の業務で役立つイメージできず、読むこと自体断念しました。 また古い本なので仕方が無いですが、出てくるツールは現在のベストプラクティスからするとやや古く、違和感を感じながら読む場面が幾度かありました。

Posted byブクログ

2021/01/31

2016年出版(原書はもっと古い)なだけあり、コンテナアプリケーションの開発で盛り上がっている現在では、内容が少し古い ただ、考え方の原理原則は転用が効くので、そこはしっかりと学ぶべき

Posted byブクログ

2021/08/08

もう少し知識を得た後で読んだ方が良かったかもしれない。自分には早すぎた。ある程度システム開発・運用の実務をこなしていないのとピンと来ないかもしれない。 ・チームの規模についての具体的な推奨内容はメソドロジーごとに異なるが、比較的小規模にすべきだとしているところは一致している。...

もう少し知識を得た後で読んだ方が良かったかもしれない。自分には早すぎた。ある程度システム開発・運用の実務をこなしていないのとピンと来ないかもしれない。 ・チームの規模についての具体的な推奨内容はメソドロジーごとに異なるが、比較的小規模にすべきだとしているところは一致している。Amazonには「ピザ2枚ルール」がある。つまり、チームの規模は、ピザ2枚で満足できる人数を越えてはならないということだ。 ・Amazonは、それぞれ2個のディスクを接続する6万4000台のサーバーを持つデータセンターでは、毎日平均して5台以上のサーバーと17個のディスクが壊れるというデータを公開している。 ・Amazonのチームに関する規則  ・すべてのチームは、今後、サービスインタフェースを介してデータと機能を他チームに提示する。  ・チームは、これらのインターフェースを介して互いにやり取りしなければならない。  ・これ以外の形態のサービス間、チーム間通信は認めない。直接リンクしたり、ほかのチームのデータストアを直接読み出したり、共有メモリモデルを使ったり、その他いかなる形でも裏口を作ることを認めない。認められている通信は、ネットワークを経由したサービスインターフェース呼び出しだけだ。  ・彼ら(ほかのサービス)がどんなテクノロジーを使っても口出しをしない。  ・すべてのサービスインタフェースは、例外なく、外部からアクセスできるように0から設計しなければならない。つまり、チームは外部のデベロッパに対するインタフェースを提供できるようにプランを立て設計をしなければならない。 ・DepOpsの実践には5つのカテゴリ  1.要件の視点から、運用を正規のステークホルダーとして扱う。  2.重要なインシデント処理における開発の仕事を増やす。  3.開発と運用の両方の担当者を含む全員に新たなデプロイプロセスを強制的に使わせる。  4.継続的デプロイを使う。  5.アプリケーションコードと同じ実践を使ってインフラストラクチュアコードを開発する。 ・セキュリティのための5つの設計原則  1.クライアントには、タスクを実行するために必要な特権のなかで最小のものを提供する。  2.メカニズムはできる限り小さくてシンプルなものにする。  3.すべてのオブジェクトにたいするすべてのアクセスを必ずチェックする。  4.複数のユーザーに共通なメカニズムやすべてのユーザーが使うメカニズムを最小限に抑える。  5.フェールセーフなデフォルトを使う。 ・DevOpsパイプラインの○○性とその意味  反復可能性:同じ操作の繰り返しがどの程度可能か  処理性能:DevOpsの操作を実行するために必要な時間とリソース  信頼性:DevOpsパイプラインとそのなかに含まれる個々のソフトウェアが決められた期間にわたってどの程度サービスを維持できるか  回復可能性:失敗したDevOps操作を、操作対象のアプリケーションに与える影響が最小限に抑えられた望ましい状態にどの程度回復できるか。  相互運用性:異なるDevOpsツールが特定のコンテキストでインターフェースを介してどの程度有益に情報を交換できるか。  テスト可能性:DevOpsソフトウェアがテストを通じてどの程度か単に自らの誤りを示すことができるか。  変更可能性:DevOpsソフトウェア、プロセス、アプリケーションの操作環境を書き換えるためにどの程度の労力が必要か。

Posted byブクログ

2017/05/02

‪マイクロサービスとCI・CDについて調べていたので第2部と第4部を読んだ。AmazonのルールやAtlassianの移行の実例、あとCDCの概念が勉強になった。参考文献も詳しいし、他の部分も手厚そうなので今後もリファレンス的に使いたい。難点を挙げると少し日本語訳が読みづらいかな...

‪マイクロサービスとCI・CDについて調べていたので第2部と第4部を読んだ。AmazonのルールやAtlassianの移行の実例、あとCDCの概念が勉強になった。参考文献も詳しいし、他の部分も手厚そうなので今後もリファレンス的に使いたい。難点を挙げると少し日本語訳が読みづらいかな…‬

Posted byブクログ

2016/11/22

一般に言われるDevOpsより扱っている範囲は広い(セキュリティ、アカウント管理等)こともあり、少々記述が冗長でまとまりきっていないような印象は受ける。具体的なツールを挙げるというよりは、どういう考え方を持つべきかという点に着目した形なので、読むのにはわりと骨が折れた。もう一段階...

一般に言われるDevOpsより扱っている範囲は広い(セキュリティ、アカウント管理等)こともあり、少々記述が冗長でまとまりきっていないような印象は受ける。具体的なツールを挙げるというよりは、どういう考え方を持つべきかという点に着目した形なので、読むのにはわりと骨が折れた。もう一段階具体的なレイヤーに落とし込んでくれるとよかったようにも思う。

Posted byブクログ