《DevOps软件架构师行动指南》读书笔记
2021-07-28 08:51:41 5 举报AI智能生成
登录查看完整内容
DevOps是在保证质量的前提下，提供的一整套从开发，测试到生产运维的持续交付和管控方法论。在整个过程中需要实现自动化，可视化，流水线式作用，同时将质量管控无缝嵌入其中。
作者其他创作
大纲/内容
1.部署对系统的变更时（通常是代码形式），质量很重要。2.这个定义要求交付机制也是高质量的。3.我们认为有两个时间周期很重要。一个是开发人员提交新开发的代码的时间。这标志着基本的开发过程结束，部署工作开始。另一个是把代码部署到生产环境的时间。4.我们的定义是目标导向的。5.最后，定义中说明的目标并不限于DevOps用于测试和部署的实践。
DevOps对部署的要求
1.从需求的角度把运维人员视为首要干系人。这些实践符合定义中高质量方面的要求。运维人员有一套与日志及监控相关的需求。2.让开发人员更多地负责相关事件处理。新部署的内容在开始一段时间由开发人员负主要责任，之后由运维人员负主要责任。3.强制推行所有人使用的部署过程，包括开发人员和运维人员。确保更高的部署质量。4.使用持续部署。5.在开发诸如部署脚本这样的基础设施代码时，也应遵守一套与应用程序代码相同的实践。
最佳实践要求
运维人员能力有限。
减少运维复杂度。
DevOps运动采用一种不同的方法。它们的方法把以前由运维人员完成的很多任务都自动化了，并让开发人员承担部分剩余的工作，通过这种方法，可以减少对专业运维人员的需求。
为什么使用DevOps
可以快速做出决定。
人少比人多更容易组成一个关系密切的群体。
人们在小团队面前比在大团队面前更容易表达意见。
一个小团队需要完成一小部分代码。围绕着一组微服务构建架构是一种好方法，它能够把这些小任务打包在一起并减少显式配合——所以我们把开发团队的输出成果称为“服务”。
小团队优势
既能与其他干系人交流，又能与团队的其他成员交流。
服务所有者
必须出色地排查故障、诊断问题
必须深入理解服务的内部，这样才能修复故障或者采用临时解决方案。
需要逐步成长为有能力的开发人员，因为他们需要编写高质量的程序并且以自动化的方式实现不断重复发生的诊断、迁移和修复工作
可靠性工程师
在部署流水线中，决定将服务进入下一步的手动角色
决定服务的某个版本或服务的某个部分是否能够通过“门”并进入下一步
看门人角色
负责DevOps工具链中使用的各种工具的护理和保养
这个角色可以是个人、团队或组织层面
选择开发团队使用的配置管理工具的哪个发布DevOps工程师职责的一部分，为开发团队定制工具并监控开发人员是否正确使用也是DevOps工程师的职责
以自动化方式实现开发和部署流水线是DevOps工程角色的固有职责
DevOps工程师
一个人可以承担多个角色，一个角色也可以由多人承担。角色的分配取决于个人能力、个人的工作负荷以及这个角色所需的能力和工作量。
团队角色
首先，不同团队开发的各部分能够在一起工作；其次，避免重复工作
为什么需要
直接的间接的持久的短暂的同步的异步的
形式
DevOps人工过程取自敏捷过程，目的是用于持久性不高的高带宽协作。站立会议和信息发射源是人工过程协作机制的两个例子。
人工协作
自动化团队协作机制，用自动化方式完成重复单调的任务，加快发现并报告错误的速度。目标之一是尽可能快地向开发人员提供反馈
自动化协作
与干系人和客户的上游协作
与运维人员的下游协作
与其他开发团队的交叉流协作
跨团队协作的方式
DevOps目标的一部分是通过使用隐性和不经常的协作代替直接的协作来实现的
团队协作
开发人员受到的激励是做出变更（发布新代码），运维人员受到的激励是不要变更。这两种不同的激励机制培育出不同的态度，可能成为文化冲突的原因
文化冲突
一个特定组织所担忧的风险取决于他们的活动领域。对一些组织来说，出现问题所带来的风险比尽快推向市场更重要
在监管领域运作的组织（金融、医疗保健、公用事业服务）有他们必须遵守的规则，如果违反了运营规则，就会面临处罚，有可能还是很严重的处罚。
在成熟、行动缓慢的领域中运作的组织（汽车或建筑行业）有很长的前置时间
某些组织的客户在切换到其他供应商（supplier)时成本很高，例如企业资源计划系统，客户因为担心运行的稳定性而不愿意冒险
组织风险
推行DevOps的障碍
01.DevOps概述
按需自助
可计量
核心
由于一个虚拟机与一个物理机上的其他虚拟机共享资源，所以虚拟机之间可能会有性能干扰。
当加载虚拟机时，取决于底层物理基础设施和需要动态加载的其他软件，可能有时间和可靠性方面的不确定性
虚拟化平台的弊端
某种程度上，Paas与传统Ops部门提供的一些服务相类似，Ops部门通常接管基础设施层的管理并向开发团队提供一组环境选项来托管他们的系统，开发团队可以在这些环境中进行选择
PAAS与Ops类比
诸如计算、读文件或者接收本地消息这样的简单请求都有接近正态的分布。
正态分布
复杂的请求，如大量的Map-Reduce任务、大型数据库的搜索或启动虚拟实例，将有像长尾这样的偏态分布
防止长尾的一个机制是取消耗时过长的违求
偏态分布
在分布式系统中，通过引入锁来维护一致性，这些锁控制访问单个数据项的顺序。但锁定数据项会带来访问这些数据项的延迟，因此，产生了各种不同的方案来维护一致性并减少由锁引起的延迟。
根据称为CAP（Consistency：一致性，Availability：可用性，Partition tolerance:分区容错性）原理的理论结果，不可能同时拥有完全可用、一致并分区的数据。最终一致性意味着当改变数据项时，分布、分区和复制的数据即便没有立即一致，在一段时间后将会一致一副本最终将变得一致。
最终一致性
数据一致性
在开发、测试和部署过程的各阶段有多个环境并不是云独有的特性，但简单地创建和迁移环境的能力是云独有的特性—像克隆新实例一样容易
多环境支持
02.云即平台
服务台的运维。服务台的员工负责处理所有的事件和服务请求，并作为所有问题的第一级处理者。
技术专家
IT服务的日常经验。这些包含周期性和重复性的维护运维、监控、备份以及设施管理
IT职能
防止内部研发的软件延期是DevOps的一个驱动力
硬件标准化
软硬件供给
恢复点目标（Recovery Point Objective，RPO）。当灾难发生时，对数据丢失的最长容忍时间是多少？如果每小时备份数据一次，则恢复点目标为1小时，因为丢失的数据可能是自上一次备份后的累积量。
恢复时间目标（Recovery Time Objective，RTO）。当灾难发生时，不能提供服务的最长容忍时间是多少？例如，如果一种方案需要10分钟来获取在另一个数据中心的备份，再需要5分钟来实例化新的服务器以便使用这些备份数据，则恢复时间目标为15分钟。
业务连续性
标准化合同松耦合抽象可复用性自治无状态可发现性可组装性
服务设计原则
服务移交包含服务的实施和交付两个阶段。DevOps和持续部署要求服务移交的交付部分高度自动化，这样它才能够处理高频率的移交，并提供更好的质量控制
标准变更（例如，经常发生和低风险的变更）常规变更紧急变更
变更类型
服务移交
开发团队分析他们自己开发的单系统监控的结果
包括基础设施的多系统监控则由运维团队负责
运维团队还负责需要一个或多个开发团队合作处理的事故上报
监控职责区分
主要焦点是要在IT服务和业务需求之间达成一致——不管这些需求是否已发生变化还是维持不变
如果这些需求已经发生变化，则对IT服务的期望变化可以关注范围、功能或者服务级别协议
如果业务需求相同，则可以扩展IT服务来更好地支持它们，但对它们的改进也可以专注在提升效率上
持续服务改进
如果认为ITIL是过于“重量级”而不适合DevOps过程，那么这个观点是短视的，并且这个观点将导致要再走过那些ITIL框架中所试图解决的“坑”。
ITIL服务移交和DevOps方法之间的一个差别在于ITTL假设非常大的发布包（需要小心计划、变更管理等）是可行的——与典型的DevOps场景中遇到的高频率的小的发布包相比。
ITIL与DevOps
03.IT服务和运维
模块是一个具有一致功能的代码单元
组件则是一个可执行单元
编译器或解释器将模块转换为二进制文件，构建器将二进制文件转换为组件
开发团队直接开发模块。组件是开发团队开发模块的结果，所以也可以说开发团队开发组件，但我们应该清楚组件的开发是开发团队的一个间接活动
微服务架构将一组提供少量功能的服务集合整合到一起，这些系统的整体功能来自多个服务。
微服务
模块和组件
客户端和服务器之间的通信协议可以是任何远程通信协议，如HTTP、RPC、SOAP等。这些服务可以提供RESTful接口，也可以不提供
远程通信协议应该是不同服务间通信的唯一方法。服务提供的接口细节仍然需要跨团队的协作。
服务通信
如果实例中不保留状态，那么销毁它就没什么代价：经过一段冷却期后，实例不再接收新的请求，并响应当前的请求，这个实例就可以被销毁了。
无状态服务的另一个额外优势是，消息可以发送给服务的任何实例，这样将有助于在实例之间进行负载均衡。
无状态服务
工作指派。一个团队可以在多个模块上工作，但让多个开发团队工作在相同模块上需要这些开发团队之间的大量协作工作。因为协作花费时间，所以更简单的一种结构是将单个团队的工作打包成模块并在开发模块之间的接口，以允许不同团队开发的模块相互操作。
分配，每个组件（即微服务）以独立的可部署单元存在
指派与分配
数量有限的团队间的协作可能导致开发客户端的团队与开发服务的团队在接口语义方面产生歧义。
DevOps中的一个重要趋势是像管理应用程序代码一样引入版本控制和测试来管理设置环境的代码和配置参数。
环境的正确性
幂等（Idempotent)是服务的一种机制，允许服务被相同的输入重复调用，同时产生相同的输出——换言之，没有产生错误。
如果服务失败，客户端可以执行替代操作。
实例故障
问题来源
可靠性
使服务具有更灵活的可修改性的方法有：1）封装可能变化的影响部分；2）封装可能引起变化的连锁反应的交互部分。
可修改性
所有团队通过服务接口开放他们的数据和功能。
团队必须通过接口与其他团队通信。
不允许其他形式的服务间/团队间的通信：没有直接链接、不能直接访问其他团队的数据存储、没有共享内存模式、没有后门等。允许的唯一通信是通过网络上的服务接口调用。
不用关心他们（其他服务）使用了何种技术。
所有服务接口，无一例外，都要在一开始就设计成可以外部化的。
服务级别协议绑定了客户端和服务器端。如果客户端的需求超越了服务级别协议中承诺的工作负荷，则响应速度慢就变成客户端的问题，而不是服务端的问题。
亚马逊规则
在需求规格说明时考虑运维关注的部分。被开发的系统整体结构应该是一个小的、独立的服务组成的集合。对于客户端和其他需要的服务，每个服务都是不可信的。需要定义和理解团队角色。服务需要注册到本地的注册表/负载均衡器。服务必须周期性地刷新它们的注册信息。服务需要给客户端提供服务级别协议。服务要设计成无状态且短暂的。如果服务必须维护状态，则它应该在外部持久存储上维护状态数据。如果服务所依赖的其他服务发生了故障，则需要备用方案。服务有防御检查，以便拦截来自客户端的错误输入或其他服务的输出。外部服务、环境信息、第三方软件和库的使用都应该本地化（例如，它们要求通过特定于那个外部服务、环境信息、外部软件或库的模块）。
微服务方案
04.整体架构
团队成员可以并行地在系统的不同版本上工作一个团队成员开发的代码不会在无意中覆盖另一个团队成员开发的代码。如果一个团队成员突然离开团队，工作不会丢失。团队成员的代码易于测试。团队成员的代码可以容易地与同一个团队的其他成员编写的代码集成在一起。一个团队开发的代码可以容易地与其他团队开发的代码集成在一起。系统的集成版本可以容易地部署到不同环境中（例如，测试环境、预发布环境（staging）、生产环境）。系统的集成版本可以在不影响系统生产的版本的情况下容易且完整地测试。可以对系统最近部署的新版本进行密切监控。一旦代码放入生产环境，如果出现问题，能够找到旧版本的代码。万一出现问题代码可以回滚。
整体要求
定义持续集成的一种方法是在一个阶段与下一阶段之间有一个自动触发器，直到集成测试。即，如果构建成功，则触发集成测试。如果不成功、则通知对失败负有责任的开发人员。持续交付定义为，使用自动触发器，直到预发布系统。
我们用术语预发布（staging）描述这些不同的功能。持续部署意味着到最后一步（即部署到生产系统）也是自动化的。在将服务部署到生产环境之后会密切监控一段时间，然后将它升级到正式生产系统。
CI/CD
Git与Cms:把所有的东西都放入版本控制或配置管理系统让你能够在任何一个地方重新创建准确的环境，从本地环境到生产环境。
·允许可追溯性的第一个选择是把起标识作用的标签与打包的应用程序关联起来。·另一个选择是把生产环境中每个机器的起源放到一个外部配置管理系统中。
可追溯性
本地：开发人员的笔记本，台式机/工作站。开发:开发服务器，也称为沙盒。集成：持续集成（Continuous Integration，CI)构建目标，或者用于开发人员测试副作用。测试/质量保证（Quality Assurance，QA)：用于功能、性能测试、质量保证等。UAT：用户验收测试。预发布/生产前：生产环境的镜像。生产环境/实时：服务于终端用户/客户。
环境
测试框架是一组软件及配置的测试数据，通过在各种条件下运行它，并对它的行为及输出进行监控，以便测试一个程序单元。测试框架是必需的以便自动测试。测试框架的一个关键特征是，它产生报表。特别是、它应该至少识别出哪个测试失败了。
测试框架
测试系统行为是否符合预定也是很重要的。为这个目的所做的测试统称为负面测试。
负面测试
回归测试是在通过最初的测试后维护并重新运行测试的根本原因。“在对系统现有的功能及非功能领域进行改进、打补丁或配置更改等变更后力求发现新的软件缺陷，或者叫作回归。”
回归测试
当一个环境不再用于某个特定目的时，如预发布测试，就应该将它拆解。拆解环境的一个原因是释放与此环境相关的资源，另一个原因避免无意间与这些资源进行交互
环境拆解
横切关注点
能够环境识别源代码不同的版本；不同开发人员之间共享代码修订；记录从一个版本到下一个版本之间谁做了修改；记录修改范围。
核心功能
CVS和SVN是集中式解决方案，其中每个开发人员都从中央服务器上检查代码，然后将变更提交回这台服务器。
SVN
每个开发人员都有包含所有内容的Git存储库的一个本地克隆（或副本）。提交是在本地存储库完成的。一系列变更可以通过中央服务器进行同步，其中服务器的变更与本地存储库同步（使用pull命令）。本地变更可以提交给服务器上使用（使用push命令）。
GIT
1）分支可能太多，你不知道特定任务应该在哪一个分支上完成。2）合并两个分支可能是困难的。
分支结构的一个替代方案是让所有开发人员都在主干上直接工作。与使用分支相比，它需要更频繁的操作。所有开发工作都在一个主干上的问题是，会在部署流水线中的新功能中引入不完整或未测试的代码。为了解决这个问题，提出了功能开关。
替代方案
功能开关允许你挂续地交付新发布，这些版本可以包含未完成的新功能—但这些不会影响应用程序，因为这些新功能还处于关团状态。教训1：不要重复使用开关名称。教训2：尽可能快地集成功能并去掉开关测试
功能开关
分支管理的两个问题
版本控制与分支
配置参数的数量应该保持在一个可管理的水平。较多的配置参数通常会导致它们之间的复杂联系，多个参数之间的兼容设置集也只有几个软件配置专家才知道。虽然灵活性是我们期望的目标，但太复杂的配置意味着你基本上是在创建一个专属的编程语言。
配置参数简单化
持续集成服务器得到新提交的通知或者定期检查是否有新提交。在检测到新的提交时，持续集成服务器可以检索它。持续集成服务器运行构建脚本。如果构建成功，则持续集成服务器运行自动化测试。持续集成服务器把它的活动的结果提供给开发团队（例如，通过内部网页或电子邮件）。
持续集成（CI）步骤
用户验收测试（User Aceptance Test，UAT）是预期用户使用系统当前版本的用户界面所做的测试，可以根据测试脚本测试，也可以使用探索性测试方式。
自动化验收测试是可重复的用户验收测试的自动化版本。自动化验收测试在白天或夜间的少量时间能够完成更多可重复性的工作。
冒烟测试是自动化的验收测试的一个子集，用于快速分析提交的代码是否破坏了应用程序的某些核心功能。一个密闭的流水线系统充满了烟雾，如果发生了泄漏，可以容易地检测到烟雾。
非功能测试是对性能、安全、容量及可用性等方面的测试
早期发布的几种方式:最传统的方法是beta发布。金丝雀测试方法是把新版本首先部署到几台服务器上，观察它们如何执行。A/B测试与金丝雀测试相似，差别仅在于A/B测试的目的是，对于特定的业务的关键绩效指标（Key Performance Indicator)来说，确定哪个版本执行得更好。
测试的另一种形式是干扰正在运行的系统。这种形式称为现场测试（Live testing）。
用户验收测试/预发布/性能测试
05.构建和测试
对系统用户产生最小影响的情况下，将服务的升级版本投入生产环境中，这些影响可能是失败或者停机时间。
目标
修复错误、提高服务的质量，或者增加新功能
服务变更的3个原因
蓝/绿部署（有时称为大翻转或者红/黑部署）包括了N合提供版本A服务的虚拟机，同时还准备N台版本B的虚拟机。一旦版本B的N台虚拟机配置好并准备服务请求，那么客户请求就能够路由到版本B。
该模式的一种变体是逐步进行流量切换。先将小部分违求先被路由到版本B，可以有效地进行金丝雀测试。
蓝绿部署
滚动升级包括将少量版本B的虚拟机一次直接部署到当前生产环境中，同时关闭相同数量的运行版本A的虚拟机。
滚动升级期间，一部分虚拟机提供版本A的服务，而其余的虚拟机提供版本B的服务。这会造成由于版本混合而带来失败的可能。
滚动升级
两个策略
相同服务的多个版本会同时存在。服务与其客户之间在功能上的不一致性。服务与保存在数据库中的数据之间的不一致性。
几种不同的技术可以防止这种情况使客户端版本知道从而使它了解最初的请求是由版本B的虚拟机服务的。然后它能够要求第二个请求由版本B的虚拟机提供服务。切换版本B和客户端中包含的新功能，以便在任何给定的时间仅有一个版本提供服务。使服务向前和向后兼容，并在特定请求没有得到选择时使客户端意识到。
如何防止
逻辑不一致性
除了维护各种服务之间的兼容性外，一些服务必须还能够以一致的方式读/写数据库。最基本解决方法是不修改现有字段，但只增加新的字段或表，这样做就能够不影响现有的代码。
数据库一致性
将多个服务打包到相同虚拟机中有可能造成部署竞态条件
两个团队的供给流程有重合
在同一个虚拟机中包含多个服务是在降低延迟与可能的部署竞态条件之间进行权衡
部署竞态条件
从根本上来说，通过部署物理上和逻辑上相互分隔的站点来实现业务连续性
如果你将系统的虚拟机部署到不同地区、那么你对停机格将有更多防护，因为某些服务，如弹性负载平衡，是每地区独立的。
无状态服务的缺点是状态必须维护在系统的某个地方；当服务需要获取或修改这个状态时，可能会增加延迟。延迟增加的一个后果是服务可能会在本地缓存状态。这就意味着在某些环境中你需要清理缓存。少量状态可以用Memcached（正如其名称所表示的，它就是专为缓存而设计的）这样的服务进行维护。大量的状态应该维护在持久性存储库中。
拥有两个完全相同的数据中心的一个更大的优点是：当一个数掘中心上的预期负载比较低时，可以在这段时间内使用该数据中心进行生产前测试。
如果A或B在一些业务度量（比如已下订单）中表现出更好的行为，那么这个版本变成生产版本，而另一个版本则报废。
A/B测试
由于回滚的敏感性以及前滚的可能性，所以自动触发回滚很少。应该有一个人在决策圈中，他决定错误是否严重到应该停止当前的部署。这个人随后决定回滚还是前滚。
当发现错误时，关注点是错误数据已经写入数据库
回滚那些已激活新功能的服务所处理的请求，并使用旧的、可工作的服务来重放它们。
错误数据值可能对外部有影响。例如，客户可能已经看到了被大幅削减的票价并完成了购票
人为控制的回滚
一个新兴的趋势是在部署中使用轻量级的容器工具，比如Docker。轻量级容器是操作系统级的虚拟化技术，用于在单个主机上（虚拟机或物理机）运行多个独立的操作系统。它们类似于虚拟机，但它们更小且启动得更快。
轻量级工具
06.部署
1）识别故障以及相关的缺陷，既包括执行时的，也包括故障发生后在反思会上发现的。2）识别单一系统和一组交互系统的性能问题。3）为长期和短期容量规划和付账目的而描述工作负荷。4）度量用户对接口和业务产品的各种反应。5）检测企图入侵系统的入侵者。
五种类型
检测软件故障可以归纳为以下3种：1）监控软件从外部点对系统进行健康检查。2)系统内的特殊代理执行监控。3）系统自己检测到问题并发出报告。
三种故障检测方式
容量规划过程的输入包括：1）从监控数据收集的当前工作负荷特征；2）基于业务考虑和当前工作负荷所做出的未来工作负荷的预测。
监控数据也用于公有云的计费。为了实现为使用付费，使用量必须能够判断出来、这是通过云供应商的监控来完成的。
容量规划
用户交互
人侵检测器是一个软件应用程序，它通过查看异常来监控网络流量
入侵检测
如果系统主动地提供了被监控的数据，那么监控是入侵式的且影响系统设计。如果系统不主动提供被监控的数据，那么监控是非入侵式的且不会影响系统设计。
基于代理的方案和无代理的方案都有各自的优势和弱点。无代理方案在部署和维护方面占优势。但是，如果存储库在你网络的外面，那么它是不安全的，因为，系统需要开放很多端口且防火墙规则会放宽以允许系统的不同层与外部世界进行数据通信。相反，主机上的代理可以与操作系统和应用程序进行本地通信并从一个通道发送所有收集到的信息。同时，基于代理的方法能够优化网络传输和处理开销。
代理和无代理
由于监控数据的不同使用需求不断增长，所以很多公司开始为监控系统和整体应用系统采用统一的日志和以指标为中心的发布-订阅架构。越来越多的数据类型，包括非传统日志和指标数据，都放入统一的存储库中，其中各种其他系统（不管是否与监控相关）都可以订阅其感兴趣的数据。
ELK
如何监控
时间序列数据
生成日志的一般规则？日志应该有一致的格式。日志应该包含解释为什么要生成这类日志消息。
日志条目应该包含上下文信息。上下文信息不仅仅是旦期和时间，还应该包括支持追踪日志条目的信息：·代码中的日志条目的来源。·生成日志条目时进程执行的进程号。·导致进程执行这个日志生成器的请求的请求ID。.生成日志消息的虚拟机的VMID。日志应该包含筛选信息。
日志
怎样配置监控系统以减少误报（不需要响应的警报）和漏报（需要采取行动但警报没有提示）？怎样配置监控系统使得警告能提供诊断警报的所需信息？一些用于收善警告和警报有效性的通用规则是？为警报引入背景信息。如果发生某些事件则不仅要触发警报，而且，如果期望发生的事件未发生，则也要设置触发警报。将那些可能指向相同事件的不同警告汇聚在一起。设置清晰的严重等级和紧迫性等级，这样接收到警告的人或系统可以采取相应的措施。
典型问题
变更是常态。系统基础设施和系统本身的持续变更使得监控参数的设置变得复杂
持续变更下的监控
第一，将有更多的单个模块级别和其他低级别的内容被监控。第二，这挑战与云弹性和自动化导致的持续变更有关。
自下向上与自上向下和在云中的监控
怎么识别并修复响应慢的节点
监控微服务架构
1）在很小时间间隔内收集指标的性能开销是巨大的。取决于系统当前的状态，运维应该使用变化的和可调节的时间间隔，而不是一些固定的时间间隔。2）应该使用现代分布式日志或消息系统来进行数据收集，而不是自己构建一个。分布式日志系统（如Logstash)能收集所有种类的日志，并在数据运输前进行大量的本地处理。
3）研究人员开始使用高级机器学习算法来处理噪声、不一致性和大容量数据。
Linkedln开发了Kaka，一个高性能的分布式消息系统，它主要用于日志聚合和监控数据收集。它采用面向事件的架构，并将输入的数据流与处理过程解耦。
处理大容量的分布式（日志）数据
挑战
07.监控
CIA代表了机密性（Confidentiality)、完整性（Integrity）和可用性（Availability)。机密性意味着没有未经授权的人可以访问信息；完整性意味着没有未经授权的人可以修改信息；可用性意味着经过授权的人员可以访问信息。
CIA
微软引入了简写为STRIDE的威胁模型。STRIDE代表：身份欺骗篡改数据否认性信息泄露拒绝服务权限提升
STRIDE
把攻击的动因宽泛地描述为：经济利益的。知识产权。破坏。
攻击动因
微服务具有的小规模特性使得它更容易执行特定服务的安全策略。
技术控制有3种类别：通道内的控制。这些控制允许合法用户访问网络、认证用户以及授权用户访回信息或资源。通道外的控制。这些控制的目的是阻止通过非批准的通道进行访问。例如，旁路攻击（side channel atack)利用计时、功耗方面的漏润以及声波和电磁泄漏来获得有用的信息。审计。系统内的各种活动都应该以记录的形式保留下来，例如资源的使用、数据的访问和数据的修改。
技术控制
为了审计的目的，身份管理任务中的所有活动都应该记录在日志中——不仅是人触发的活动，而且也要包括通过工具或者脚本执行的活动。服务或者微服务之间的调用也需要认证。
身份管理
如何认证？在安全领域中，你作为个体，有3种方法来认证你。这些是你知道的某些事物（例如，密码）、你拥有的事物（例如，智能卡）或者表征着是你的事物（例如，指纹）。
设备注册:对这个专用计算机进行注册可以防止使用一个欺骗性的维护计算机来破坏你的系统。存在两种基本的技术支持一个系统使用用户凭证来访问另一个系统。一种技术是单点登录（Single Sign-On，SSO），另一种技术是使用独立的、由系统管理的凭证。
基于角色的认证的问题是缺少可追踪性。一个问题可以追踪到“超级用户”，但不能追踪到个体。
认证
能力：能力是令牌，该令牌授予对资源的特定权限。
不管使用哪种技术来控制访问，都应该采用最小化权限（Least Posilble Privilcge）对用户或者角色授权以使他们能够执行其所需要的任务。
授权
定义边界:组织的网络可以划分成子网（subnet)，每个子网有自己的边界。
隔离:隔离是与边界检查相关的技术。物理分离一直以来都有被使用——不要把你想保护的资源连接到因特网上，并且限制对这些资源的物理访问。当访问系统的主要方式是通过因特网时，物理分离是不可行的。
加密:为了防止攻击者获取对数据的访问，不管数据是静止的还是在传输中的，都可以使用加密来保护数据。
阻止访问
防御性编程（defenive progamming）和对进入消息（incoming mesage)缺乏信任是表征安全开发原则的两个设计实践。
安全开发原则
不要把审计追踪和日志混为一谈。审计追踪会持续存在数月或者数年且具有法律地位，主要用于安全目的。日志持续存在的时间是以日（甚至更短）来计算的，它主要用于支持运维和开发的需求。
审计和日志的区别
边界控制设备可以过滤特定类型的包并限制被访问的端口以保护内部系统。限速（Rate-limiting)或者流量整形（Trafic-shaping）交换机也用于抵抗拒绝服务攻击。
拒绝服务攻击
安全的5个设计原则是：1）为客户提供完成他们任务所需的最小权限。2）机制应该尽可能地小和简单。3）对每个对象的每次访问都必须检查，不仅仅在正常使用中，而且还要在初始化、关闭和重启中。4）把由多个用户共享而且被所有用户所依赖的机制的数量减少到最少。每个共享的机制都是一个潜在的信息路径。5）利用故障安全（fail-safe)默认项。在部署流水线中，系统必须经过的一个安全闸门（Security Gate)是对编码实践的测试。另一个是对各种运行时攻击方法进行测试，例如跨站脚本（cross-site scripting)。
安全的五个原则
08.安全与安全审计
“非功能需求”这个词，它用来描述软件的质量关注点，而不是关注软件的基本功能和正确性。
任何改变基础设施或者环境的脚本或者代码都应该置于版本控制之下，与应用代码被版本系统控制一样。
不但脚本/代码的所有历史版本都是可用的，而且关于这些脚本/代码变更的信息也保留下来，例如变更的理由、谁做了变更和变更的时间。
完成这项工作的一些可能的方法和工具是：部署工具。可以通过部署工具来实现维护高层级过程的可追踪性。配置管理数据库（Configuration Management Database，CMDB)。对数据项打标签。
版本控制
把以上的所有环境都迁移到云上，从而关闭那些当前未被充分利用的服务器，并仅为你所使用的资源付费。
使用容器而不使用虚拟机
弊端是，如果环境是托管在第三方云上，那么你就失去了对你环境的完全控制和可视化。同时，也存在着小概率但影响巨大的风险，例如整个开发和测试环境的服务中断等
提高资源使用率
1）在操作逻辑中包含大量异常处理（exception handling)。2）内置对外部监控或者恢复系统的支持。3）在设计软件时，把运维人员视为首要的干系人。4）使长时间运行的操作的每个独立步骤都能够自我恢复，这样只有在很少的情况下才需要回滚整个操作。
如何达到可恢复性
DevOps流水线可以看作一个处理各种分布式服务的分布式超级系统。这些服务和它们的可靠性通常不在你的直接控制下。为了提高流水线的可靠性，你可以应用一些解决方案。
单元和集成测试使你对代码质量和预期的行为产生了信心。然而，执行模拟真实生产环境的太规植系统测试仍然是一个难以实现的任务。
可测试性
实现软性内可修改性的一个基本技术是，将相关活动封装成模块，并使各个模块之间尽可能地松耦合。把相关活动保持在一个模块内的理由是，该模块内一个活动的变更将需要膜内的其他活动也发生变更，但是希望这些变更不要扩展到一个模块之处。
把变量参数化而不是把这些变量构建到代码中
处理流水线中的一个工具的修改
处理流水线中的工具之间的交互的修改
可重复性性能可靠性可恢复性互操作性可测试性可修改性
总结非功能性七大需求
09.其他非功能需求
让管理层确信这些变更所带来的收益大于成本。
在以下4个方面说服管理层：1）存在一个被攻击的真实问题；2）能决问题的方法是合理的；3）解决问题所带来的好处大于成本；4）干系人不会过于失望。
当前价值和目标价值之间的差值表示DevOps带来的好处。这些价值不必是财务的
管理层的支持
与DevOps相关联的成本中有一部分是持续成本，有一部分是一次性成本。持续成本与工具和人有关。
一次性成本是引入DevOps实践的直接花费。
另一种一次性成本是修改现有系统以支持DevOps实践的花费。
成本
一旦事故发生了，有3个可能的情况：1）事故显然与应用有关。这种情况下，Dev组是管理该事故的初始联系人。2）事故与硬件或者基础设施故障有关。这种情况下，Ops负责诊断和修复故障。3）事故的原因是不明确的。
事故处理
DevOps实践的业务案例包括成本、收益、风险和风险减缓、推出规划和成功标准
10.业务关注点
受控的迁移是指，主数据中心依然可用，在切换到辅助数据中心前有时间进行各种准备措施。非受控的迁移作为一个灾难（不管是自然的还是人为的）的结果而发生。
受控与非受控的迁移
数据中心可以处于以下3种状态之一：活跃的、非活跃的、离线的。活跃的意思是，在这个数据中心内的服务器上没有任何限制。非活跃的意思是，定时任务、守护程序和后端应用程序都是停止的和被禁用的。
数据中心状态
诊断是发生在检测错误之后的活动，它可以是在线的或者离线的。快速在线诊断可能带来更明确的恢复，但是对底层问题的详细分析最好是离线完成的，恢复后把系统恢复到稳定状态。
为了诊断运维错误，我们使用故障树作为参考模型。在这样的故树中，每个节点代表了一个故障或者错误，这个故障或者错误又相应地可能是由子节点代表的错误所引起的。
诊断
一致性检查可以检测到以下类型的错误：未知的：完全未知的日志行。错误：对应于一种已知错误的日志行。不适合的：对应于已知活动的日志行，但是根据过程实例当前执行状态，这个活动不应该发生。
一致性检查
11.运维补充
抵御厂商锁定的解决方案包括：防御性编程（defensive programming)。迁移程序（migration program)。
提供开放的应用程序编程接口（AP1）并为工具之间的互操作性推动建立一个活跃的插件生态系统。
避免厂商锁定
在云平台上用于对资源计费的模型分为4类：1）基于消费的。基于预先声明的计划，支付你所使用资源的费用。2）基于套餐的。在一个特定的时间周期内（例如，一个月），一次支付可以无限使用或者在一定上限内使用。3）基于广告的。允许在你的网页或者显示器上投放广告以换来费用的减少。4）基于市场的。在特定时间，基于供求关系来决定支付多少。
计费模型
通过3个方面获得质量。1）不要做任何愚蠢的事。2）自动化的检测错误、诊断错误和从错误中恢复。3）预测运维结束时间。
质量
12.DevOps未来
《DevOps软件架构师行动指南》-伦思·拜斯（Len Bass)
0 条评论
回复 删除
下一页
