具体描述
在开发和运维方面，如今的大型网站承受着巨大的压力。随着敏捷方法的实施，问题变得更加严重。管理网站、部署应用、维护运作等任务的顺利实施，无不需要开发与运维合为一体，而这两种团队并不一定能够完美融合。如果他们彼此隔阂，只会增加项目复杂度，进而影响最终的用户体验。
针对此问题，本书阐述了“开发运维”的概念，即DevOps，探讨了如何高效、规范地进行Web开发与运维，就创建与维护大型网站所需达成的工程目标及重点业务，为开发和运维人员提供了翔实中肯的策略及建议，从而能够加速产品开发，保证应用的实时性、高扩展性及可靠性，继而塑造出一支合作无间的精英团队，形成良性的生产循环。
本书针对大型网站及移动网站开发运维的现状问题，结合敏捷方法，阐述了“开发运维”（DevOps）这一理念，作者分享了在创建和运维大型生产网站时所需要的经验，讲述了如何综合运用系统、代码和进程来使大型网站的开发和运维变得超级高效。
本书适合Web开发及运维人员，以及项目经理阅读。
作者简介
作者：
Matthew Sacks 专门从事大规模网站和应用开发的系统管理员和程序员。他曾经是Java和Python程序员，出席过USENIX LISA和ApacheCon，也是USENIX博客团队的创始人。
译者：
曾少宁 现为一名高校教师。曾经在国际知名IT企业任职Java软件工程师，另有多年的Web开发经验，翻译过多本技术书籍。
目录信息
第1 章 成功网站的开发运维原则 1
1.1 深入理解网站开发与运维 3
1.1.1 展开协作 7
1.1.2 提升效率 10
1.1.3 推进协作 11
1.1.4 处理变更 13
1.1.5 展望未来 17
1.2 来自专家的见解 18
1.2.1 软件工程师眼里的开发运维 18
1.2.2 运维工程师眼里的开发运维 21
1.3 本章小结 22
第2 章 协调开发人员与业务运维人员 25
2.1 平衡技术人员与业务人员的关系 26
2 | 深入网站开发和运维
2.2 理解开发者文化 27
2.2.1 专业技能分类 29
2.2.2 人才与激励 30
2.3 业务人员与IT 人员之间的健康关系 31
2.3.1 业务人员要理解技术能力 31
2.3.2 业务成功符合工程人员的既得利益 32
2.3.3 业务人员与IT 人员要相互理解 32
2.3.4 业务管理层要让IT 人员参与决策制定过程 32
2.3.5 利用工具形成通用词汇表 34
2.3.6 跑在截止日期之前 35
2.3.7 释放紧张环境的压力 36
2.3.8 让业务部门感受到激励 36
2.4 内部敌人 36
2.4.1 认清形势 37
2.4.2 向主管提建议可能很困难 38
2.4.3 突破界限 39
2.5 改善业务人员与工程人员的沟通 40
2.5.1 定义与执行 41
2.5.2 广开言路 41
2.6 本章小结 42
第3 章 Web 测试实践 43
3.1 Web 测试实践 45
3.1.1 最大容量测试 46
3.1.2 持续负载测试 47
3.2 行为驱动开发 48
3.2.1 Santiago Suarez Ordo?ez 的自动化Web 测试 52
3.2.2 将安全性视为测试实践 54
3.3 确定测试对象 54
3.4 指标吻合度测试：确定测试目标 55
3.4.1 网站的业务指标 56
3.4.2 Web 应用性能指标 60
3.4.3 基于指标模板的应用程序性能指标监控实践 60
3.5 测试各个组件，快速修复故障 63
3.6 逐层保存历史性能数据 65
3.7 本章小结 68
第4 章 设计聪明的文档 69
4.1 鲜为人知的文档优点 70
4.2 文档编写的拦路虎 72
4.2.1 场景1：时间不够 72
4.2.2 场景2：只有技术文档 74
4.2.3 场景3：文档很快会过时 76
4.3 文档类型与模板 77
4.3.1 API 规范与参考文档 78
4.3.2 入门指南 80
4.3.3 用例文档 82
4.3.4 用户交互工作流程 84
4.3.5 架构图 85
4.3.6 基础架构设计文档 87
4.4 自动化文档编写 89
4.5 本章小结 89
第5 章 基础架构与应用程序的自动分配 91
5.1 回顾Web 层次 92
5.1.1 通过自动化实现统一的Web 环境 93
5.1.2 提前计算自动化的效果 95
5.2 选择自动化流程 97
5.3 一个自动化场景 101
5.4 降低复杂性 104
5.5 选择配置管理和分配框架 105
5.6 审核基础架构 106
5.7 使用配置管理系统实现自动部署 108
5.8 本章小结 109
第6 章 生产发布 111
6.1 认识整个过程 112
6.2 网站的概念开发：概念设计 113
6.2.1 概念设计要解决的基本问题 114
6.2.2 成本/收益分析 116
6.2.3 特别项目团队 117
6.3 营销 118
6.4 设计发布元素 119
6.5 灵感与愿景 122
6.6 开发 123
6.6.1 处理偏离计划的问题 123
6.6.2 研发性网站 124
6.7 测试 124
6.7.1 最终用户测试 125
6.7.2 性能测试 125
6.7.3 代码分析 128
6.7.4 生产环境测试 129
6.7.5 安全测试 131
6.7.6 携带负载的压力测试 132
6.8 发布前阶段 134
6.9 发布阶段的负面因素：常见的人员问题 135
6.9.1 不够重视 136
6.9.2 人手不足 136
6.9.3 睡眠不足 137
6.10 成功发布：防止耗竭 138
6.10.1 专责团队 138
6.10.2 特别项目团队的轮转 139
6.10.3 准备应付最坏情况 140
6.10.4 在产品发布过程中保持旺盛斗志 140
6.10.5 成功标准 141
6.11 实现一次成功的产品发布 142
6.12 本章小结 143
第7 章 整合移动Web 145
7.1 为不同设备提供不同体验 146
7.2 移动Web 的局限性与用户期望 147
7.2.1 用户无耐心 147
7.2.2 延迟时间长 148
7.3 理解使用模式 149
7.4 对比原生应用和移动Web 应用 152
7.5 创建一致体验 153
7.5.1 转换服务 154
7.5.2 整合原生应用 155
7.5.3 通过API 整合 155
7.6 跟踪API 使用率 157
7.7 本章小结 158
· · · · · · (收起)
读后感
网站每天都有新特性在上线，变化如此之快，还明确地分开发团队、测试团队、运维团队，是不是有问题了？举个例子，理解一个应用程序的容量，是谁的责任？这个需要开发角色明晰应用程序的架构和代码细节；需要测试角色设计并执行压力测试，需要运维角色提供用户访问特征和线上环...
评分网站每天都有新特性在上线，变化如此之快，还明确地分开发团队、测试团队、运维团队，是不是有问题了？举个例子，理解一个应用程序的容量，是谁的责任？这个需要开发角色明晰应用程序的架构和代码细节；需要测试角色设计并执行压力测试，需要运维角色提供用户访问特征和线上环...
评分网站每天都有新特性在上线，变化如此之快，还明确地分开发团队、测试团队、运维团队，是不是有问题了？举个例子，理解一个应用程序的容量，是谁的责任？这个需要开发角色明晰应用程序的架构和代码细节；需要测试角色设计并执行压力测试，需要运维角色提供用户访问特征和线上环...
评分网站每天都有新特性在上线，变化如此之快，还明确地分开发团队、测试团队、运维团队，是不是有问题了？举个例子，理解一个应用程序的容量，是谁的责任？这个需要开发角色明晰应用程序的架构和代码细节；需要测试角色设计并执行压力测试，需要运维角色提供用户访问特征和线上环...
评分网站每天都有新特性在上线，变化如此之快，还明确地分开发团队、测试团队、运维团队，是不是有问题了？举个例子，理解一个应用程序的容量，是谁的责任？这个需要开发角色明晰应用程序的架构和代码细节；需要测试角色设计并执行压力测试，需要运维角色提供用户访问特征和线上环...
用户评价
对于一本声称覆盖“开发与运维”的书籍来说，它在“开发”和“运维”之间的分配极度不平衡。我花了大量的篇幅去阅读关于项目管理流程和需求分析的章节，这些内容本该在软件工程的专著中得到更充分的讨论。然而，在真正的“运维”核心——自动化和弹性扩展方面，内容却显得单薄且缺乏操作性指导。例如，它提到了CI/CD的重要性，但对Jenkins Pipeline的Groovy脚本编写，或者GitLab CI/CD的具体配置流程，只是简单带过，没有提供任何可供复制粘贴的模板或解决实际部署冲突的经验分享。更让我感到失望的是，在涉及到**容器化技术**时，作者似乎完全错过了Kubernetes带来的范式转移。全书对Docker的使用仅停留在`docker build`和`docker run`的层面，对于Swarm、Compose的介绍更是寥寥无几，更不用说如何利用Helm来管理复杂的微服务部署了。这本书更像是一本面向“项目经理”的入门读物，而不是一个渴望掌握自动化运维利器的工程师的工具书。
评分这本书的排版和图表质量，也极大地损害了阅读体验。大量的代码示例，常常被截断在一页的中间，强迫你必须频繁地翻页才能跟上逻辑。更要命的是，书中配有的架构图，清晰度低得令人发指，那些本该展示数据流向的箭头，在打印出来后几乎模糊不清，仿佛是用一个老旧的截图工具强行放大了一般。我不得不频繁地打开浏览器，去搜索书中提到的那些关键概念的最新官方文档和高质量图示，才能真正理解作者想要表达的架构模型。这种**强迫读者进行“二次检索”**的行为，完全违背了技术书籍应该提供的便利性。如果一本讲述“深入”技术的书，连最基本的图文清晰度都无法保证，那么它在内容深度上的缺失，就更显得难以忍受了。它似乎更注重完成“出版”这个任务本身，而非保证读者的学习效率和阅读体验。
评分我本是抱着学习现代全栈架构的期望来翻阅这本所谓的“深入”之作的。然而，阅读体验更像是一场令人困惑的“时空穿梭”。书的前三分之一部分，似乎还停留在十年前的Web技术栈上，充斥着对jQuery时代事件处理的冗长叙述，以及对Apache HTTP Server配置文件的详细解析，这对于现在主流的Nginx和反向代理环境来说，显得有些脱节。当我急切地寻找关于微服务治理、Service Mesh（如Istio）的内容时，这本书却突然切换到了一大段关于**系统性能基准测试工具的介绍**，并且引用的工具版本老旧到我怀疑作者是否真正维护过最新的技术栈。更令人费解的是，作者在论述安全问题时，仅仅停留在了防止SQL注入和XSS攻击的基础层面，对于现代Web应用中更常见的CSRF防御机制的深入解析，比如Token同步或SameSite Cookie属性的实际应用，语焉不详。这种技术的年代感和内容结构的跳跃性，让我感觉作者的知识体系可能是在不同时间点、从不同资料中拼凑起来的，缺乏一个连贯且与时俱进的架构视角。
评分这本书的文字风格异常的“学术化”和“说教式”，仿佛作者是在对着一个从未接触过任何计算机知识的听众讲解概念。每一个技术名词的出现，都会伴随着一段冗长而缺乏例证的定义。比如，当谈到“幂等性”这个概念时，它花费了整整两页纸去解释“重复执行不改变结果的含义”，却完全没有给出一个在实际API设计中如何通过ETag或版本号来保证幂等的具体代码示例。这种过度解释基础概念，却在关键的“深入”环节掉链子的现象贯穿全书。我期待的是那种能直接带我进入代码深处的“黑盒拆解”，看看一个复杂的Web请求是如何从浏览器发出，经过负载均衡、应用服务器、缓存层，最后落到底层数据库的完整路径。但这本书，它只是在地图上标出了这些组件的名字，却从未提供任何一张**清晰的、带有标注的内部结构图**。读完后，我感觉自己像是参加了一场冗长枯燥的理论讲座，收获了一堆听起来很专业的术语，但实战能力却不见增长。
评分这本厚厚的书，封面设计得相当的朴素，乍一看，还以为是哪个年代久远的计算机教材，深灰色的背景上，几个略显生硬的宋体字“网站开发与运维”，让人很难对它产生太多期待。翻开目录，我立刻被它庞杂的章节安排给“劝退”了——从最基础的HTML/CSS讲起，然后跳到前端的JavaScript框架，紧接着又是后端的数据库设计、服务器配置，最后赫然出现了DevOps和云原生技术的章节。这就像一个野心勃勃的初学者，想在一部书里涵盖整个IT领域的历史变迁，结果就是每部分都蜻蜓点水，缺乏深度。比如，讲到React时，它只是粗略地介绍了组件化和生命周期，并没有深入探讨虚拟DOM的Diff算法优化，更别提如何在高并发场景下管理复杂的全局状态；而到了Linux系统管理，仅仅是罗列了几个常用的`grep`和`awk`命令，对于如何进行内核参数调优、如何构建高可用的集群，则完全是空白。读完第一部分，我感觉自己像个什么都懂一点皮毛的“万金油”，但真要上手做一个稍微复杂点的项目，这本书提供的知识点，还不如我之前看过的一些针对特定技术栈的官方文档来得实在。它更像是一份**非常宽泛的技术名词索引**，而不是一本能带你“深入”的实战指南。
评分科普如何开发和运维一个网站的流程
评分科普如何开发和运维一个网站的流程
评分实在不知道讲的是什么内容。。。
评分翻译的太差，读完没获得什么实际东西。
评分实在不知道讲的是什么内容。。。
