1. 行为准则2. 设计过程的螺旋式上升2.1. 圆锥体中的箭头进一步螺旋式上升2.2. 你现在更确定你理解了问题空间2.3. 你的原型为你的解决方案提供了越来越多的信心2.4. 随着每一次迭代，设计文档变得更加清晰和详细3. 技术设计流程3.1. 当被要求对系统进行修改时，大多数入门级工程师会直接跳入编码环节3.2. 技术设计流程可以帮助每个人就某项大型变更的设计达成一致3.3. 正确地完成、参与和领导技术设计工作是很有意义并且有价值的3.4. 单独的深入思考和协作的小组讨论3.4.1. 研究、头脑风暴和写作构成了深度工作3.4.1.1. 外界干扰是深度工作的“杀手”3.4.1.2. 避免所
1. 行为准则2. On-Call工程师2.1. On-Call工程师是应对计划外工作的第一道防线，无论是生产环境问题还是临时支持请求2.2. 将深度工作与运维工作分开，可以让团队中的大多数人专注于开发任务2.3. On-Call工程师只需专注于不可预知的运维难题和支持任务3. On-Call的工作方式3.1. On-Call的开发人员根据时间表进行轮换3.1.1. 每名合格的开发人员都会参与到轮换工作中3.2. On-Call人员的大部分时间用来处理临时性的支持请求3.2.1. bug报告、关于他们团队的软件如何运行以及使用的问题3.3. 大概每名On-Call人员最终都会遇到一起运维事故（
1. 部署环节1.1. 部署软件是指将软件包送到它们需要运行的地方的行为1.2. 移动应用的部署与核反应堆的部署不同，但同样的基本原则都适用1.3. 自动部署1.3.1. 使用脚本而不是手动步骤来部署软件1.3.2. 自动部署的可预测性更高，因为脚本的行为是可以重复的，并且有版本控制1.3.3. 当事情出错时，运维人员能够推理出部署行为1.3.4. 脚本比人更不容易犯错，而且它们消除了在部署过程中去手动调整系统、登录计算机或复制软件包的诱惑1.3.5. 高度发展的自动化催生了持续交付1.3.5.1. 通过持续交付，人力被完全从部署环节中移除1.3.5.2. 打包、测试、发布、部署，甚至展开环节
1. 行为准则2. 软件交付2.1. 你应该了解你的代码最终是如何出现在用户面前的2.2. 当软件在生产环境中稳定运行，并且被客户真实使用时，它就被交付了3. 软件交付流程3.1. 交付阶段并没有行业标准的定义3.1.1. 从打包到展开，统称为发布(release)3.1.1.1. 打包一个构件称为发布3.1.2. 把构件交付下载的过程称为发行(publishing)3.1.3. 直到一个特性在生产环境中被打开时才能称其为被“发布”了，而在这之前的一切行动都是部署(deploy)3.1.3.1. 部署的软件还不能被用户访问3.1.3.1.1. 只是被安装了而已3.1.3.2. 一旦部署，软件就
1. 行为准则2. 代码评审2.1. 代码评审是一种给予和接受反馈的专门的形式2.1.1. 大多数团队会在合并代码的修改之前进行代码评审2.1.2. 评审不是一个证明你有多聪明的机会，也不是一个橡皮图章式的官僚主义障碍2.2. 高质量的代码评审文化有助于所有具有不同经验水平的工程师的成长，并促进他们对代码库的共同理解2.3. 糟糕的代码评审文化会抑制创新，减慢开发速度，并且导致滋生怨恨情绪2.3.1. 执行不力的代码评审会成为一种有害的阻碍2.3.2. 轻率的反馈不提供任何价值，还会拖慢开发人员的速度2.3.3. 缓慢的周转时间会使代码的变化停滞不前2.3.4. 如果没有正确的评审文化，开发人
1. 行为准则2. 依赖管理2.1. 在现有的代码上增加一个依赖似乎是一个简单的决定2.2. 不要重复自己”(Don’trepeatyourself，DRY)是一个通常被教导的原则2.3. 依赖关系带来了风险2.3.1. 不兼容的变化2.3.2. 循环依赖2.3.3. 版本冲突2.3.4. 缺乏控制2.4. 相依性是指你的代码所依赖的代码2.4.1. 在编译、测试或运行期间，所有需要依赖关系的时间周期被称为依赖范围2.5. 依赖关系是在软件包管理或构建文件中声明的2.5.1. Java的Gradle或Maven配置2.5.2. Python的setup.py或requirements.txt2
1. 自己动手编写测试1.1. QA团队可以帮助你验证你的代码是否稳定，但千万不要把代码直接丢给他们，然后让他们做所有的测试1.2. 避免硬编码的值，不要重复代码1.3. 专注于测试基本功能而不是实现细节，这有助于代码库的重构1.3.1. 测试代码在重构后仍然可以运行1.4. 将测试的依赖项与常规代码的依赖项分开2. 避免过度测试2.1. 要编写那些在测试失败的时候有意义的测试，不要为了提高代码覆盖率而去提高代码覆盖率2.1.1. 测试数据库包装器、第三方类库或基本的变量赋值，即使它们能提高覆盖率指标，也是毫无价值的2.1.2. 要专注于那些对代码风险有最大影响的测试2.2. 将代码覆盖率作为
dockerstats:显示容器资源的使用情况，包括：CPU、内存、网络I/O等。dockerstats[OPTIONS][CONTAINER...]OPTIONS说明：–all,-a:显示所有的容器，包括未运行的。–format:指定返回值的模板文件。–no-stream:展示当前状态就直接退出了，不再实时更新。–no-trunc:不截断输出。实例:输出详情介绍：CONTAINERID与NAME:容器ID与名称。CPU%与MEM%:容器使用的CPU和内存的百分比。MEMUSAGE/LIMIT:容器正在使用的总内存，以及允许使用的内存总量。NETI/O:容器通过其网络接口发送和接收的数据量。B
1. 行为准则2. 编写、运行和修复测试用例会让人感觉很忙碌2.1. 测试本身才更容易成为繁忙的工作2.2. 糟糕的测试会增加开发人员的开销而不提供价值，并且还会增加测试套件的不稳定性3. 测试用途3.1. 测试可以检查代码是否正常工作3.1.1. 测试本身就可以验证软件的行为是否符合预期3.1.2. 预料之外的软件行为会给用户、开发人员和运维人员带来很多困扰3.1.3. 测试这道工序可以证明代码已经按规定生效了3.2. 保护代码不会被将来那些无意中的修改所影响3.2.1. 测试可以保护现有的行为不受新变化的影响3.3. 鼓励清爽的代码3.4. 强迫开发者试用他们自己的API3.4.1. 编写
1. 行为准则2. 日志分级2.1. 日志框架设有日志级别，它可以让运维人员根据重要性过滤消息2.2. 编程语言有精良的日志类库，让运维人员对要记录的内容和时间有更多的控制2.3. TRACE2.3.1. 一个极其精细的日志级别2.3.2. 对特定的包或类开放2.3.3. 在开发阶段之外很少使用这个级别2.4. DEBUG2.4.1. 多用于那些只在调查产品出故障时有用2.4.2. 在正常操作中没有用的日志2.5. INFO2.5.1. 一般用于输出应用程序运转良好的日志2.5.2. 不应该用于输出任何问题的指示2.6. WARN2.6.1. 一般用于提示那些潜在问题2.6.2. 一个资源已经
