商品詳細
内容紹介 | |
---|---|
販売会社/発売会社 | 日経BP社 |
発売年月日 | 2016/06/01 |
JAN | 9784822285449 |
- 書籍
- 書籍
DevOps教科書
商品が入荷した店舗:店
店頭で購入可能な商品の入荷情報となります
ご来店の際には売り切れの場合もございます
お客様宅への発送や電話でのお取り置き・お取り寄せは行っておりません
DevOps教科書
¥3,300
在庫なし
商品レビュー
3.4
5件のお客様レビュー
前半のdevopsの原理原則は、どの本よりもしっくりきた説明だったように思います。 後半は私には難解でした。いつどの場面で役に立つ知識なのか、自身の業務で役立つイメージできず、読むこと自体断念しました。 また古い本なので仕方が無いですが、出てくるツールは現在のベストプラクティスか...
前半のdevopsの原理原則は、どの本よりもしっくりきた説明だったように思います。 後半は私には難解でした。いつどの場面で役に立つ知識なのか、自身の業務で役立つイメージできず、読むこと自体断念しました。 また古い本なので仕方が無いですが、出てくるツールは現在のベストプラクティスからするとやや古く、違和感を感じながら読む場面が幾度かありました。
Posted by
2016年出版(原書はもっと古い)なだけあり、コンテナアプリケーションの開発で盛り上がっている現在では、内容が少し古い ただ、考え方の原理原則は転用が効くので、そこはしっかりと学ぶべき
Posted by
もう少し知識を得た後で読んだ方が良かったかもしれない。自分には早すぎた。ある程度システム開発・運用の実務をこなしていないのとピンと来ないかもしれない。 ・チームの規模についての具体的な推奨内容はメソドロジーごとに異なるが、比較的小規模にすべきだとしているところは一致している。...
もう少し知識を得た後で読んだ方が良かったかもしれない。自分には早すぎた。ある程度システム開発・運用の実務をこなしていないのとピンと来ないかもしれない。 ・チームの規模についての具体的な推奨内容はメソドロジーごとに異なるが、比較的小規模にすべきだとしているところは一致している。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