fix some small problems in CH0-1/1-2/1-3/2-1/2-3/2-4

Ch0-1-Abstract.tex

@@ -232,7 +232,7 @@
 	%
 	第三层含义是系统论。对于上述复杂软件系统，常常难以用其组成部件的性质去解释其整体性质。此时单纯依赖还原论方法难以驾驭其复杂性，需要借鉴系统论方法。
 
-	以系统观看软件学科发展，软件科学与自然科学、社会科学等各领域产生了千丝万缕的联系，信息物理融合、软件社会化、大数据时代的软件新形态使得软件必然成为技术-社会系统（Socio-Technical System）。人机物融合的软件系统，其复杂性本身就呈现在系统乃至系统之系统的层面上，综合性和系统性也愈来愈强。%系统观要求软件科学体系需超越传统还原论的思维藩篱。
+	以系统观看软件学科发展，软件科学与自然科学、社会科学等各领域产生了千丝万缕的联系，信息物理融合、软件社会化、大数据时代的软件新形态使得软件必然成为技术-社会系统（Socio-technical System）。人机物融合的软件系统，其复杂性本身就呈现在系统乃至系统之系统的层面上，综合性和系统性也愈来愈强。%系统观要求软件科学体系需超越传统还原论的思维藩篱。
 %
 	近年来，软件科学在系统观方向上进行了不少探索，包括：基于复杂网络来认识大规模软件系统的整体性质、基于多自主体的软件系统和方法、复杂自适应软件与系统、群体化软件开发方法等。网络化和大数据催发了融合软件系统与系统论研究的切入点，数据驱动的软件设计和优化初显端倪，在一些特定领域获得很大成功。
 	%人们对于数据驱动的软件的设计，不再遵循传统的自顶向下、分而治之、逐步精化的经典还原论法则，而是一种基于输入输出的黑盒的数据描述，训练出深度神经网络，充当所需要的软件。这种%

Ch1-2-ProgrammingLanguage.tex

@@ -247,7 +247,7 @@ Floyd-Hoare逻辑中，程序与断言是分离的，而且也无法表达活性
 
 对串行程序进行验证，可以通过一组与程序设计语言语句对应的Floyd-Hoare逻辑公理和规则，将对程序的验证转化为一组数学命题的证明。对这种逻辑进行扩展，可以进一步证明并发程序的正确性。我们可以通过描述并发任务的无干扰性(Non-interference) 、并发任务间接口的抽象，实现并发程序的验证。%另一个方面的工作使用关系型程序逻辑验证两个程序之间的关系，或者一个程序在两种输入下的行为之间的关系。前者可用于程序精化的验证，而后者则可用于信息安全性质，如信息流控制(information flow control)机制的验证。
 
-基于定理证明的验证工具可以分为两类，即基于自动定理证明器的自动验证和基于人机交互的半自动验证。常见的程序自动证明器(Program verifier)，如Dafny、Why3、VeriFast、Smallfoot等，大多都基于某种具体的程序逻辑。给定程序及其规约，证明器能够自动决定针对程序的每条语句使用程序逻辑中的何种公理或规则，并产生相应的验证断言作为证明义务。最终，由定理证明器完成对验证断言的证明。目前常见的证明器包括Z3、CVC4、Yices 2等。交互式的半自动验证工具，如Coq和Isabelle/HOL等，利用类型系统和逻辑之间的Curry-Howard同构关系，将构造证明的过程转化为编写程序的过程，而证明的正确性检查也变成了类型检查问题。这种方法的优点在于无需牺牲规约和代码的表达能力，程序规约可以用表达能力很强的逻辑(如在Coq 和Isabelle/HOL 中使用的高阶逻辑)来表示。而且证明自身在机器中有显式表示，其正确性可以被自动检查，因此无需依赖自动定理证明算法的正确性，验证的结论也就更加可信。
+基于定理证明的验证工具可以分为两类，即基于自动定理证明器的自动验证和基于人机交互的半自动验证。常见的程序自动证明器(Program Verifier)，如Dafny、Why3、VeriFast、Smallfoot等，大多都基于某种具体的程序逻辑。给定程序及其规约，证明器能够自动决定针对程序的每条语句使用程序逻辑中的何种公理或规则，并产生相应的验证断言作为证明义务。最终，由定理证明器完成对验证断言的证明。目前常见的证明器包括Z3、CVC4、Yices 2等。交互式的半自动验证工具，如Coq和Isabelle/HOL等，利用类型系统和逻辑之间的Curry-Howard同构关系，将构造证明的过程转化为编写程序的过程，而证明的正确性检查也变成了类型检查问题。这种方法的优点在于无需牺牲规约和代码的表达能力，程序规约可以用表达能力很强的逻辑(如在Coq 和Isabelle/HOL 中使用的高阶逻辑)来表示。而且证明自身在机器中有显式表示，其正确性可以被自动检查，因此无需依赖自动定理证明算法的正确性，验证的结论也就更加可信。
 
 近期提出的K框架提供了基于重写的语言~\cite{Rosu15}，用于定义编程语言的正式操作语义。K语言的语义是可执行的。结合K语言语义及相应的逻辑推理过程，可以分析和验证各种程序，而无需为语言提供任何其他语言（公理或指称或动态等）语义。
 

Ch1-3-SystemSoftware.tex

@@ -82,7 +82,7 @@
 	\begin{itemize}
 		\item 在资源的管控方面，此类操作系统的核心是大型主机时代即已出现的虚拟化技术，但将其应用场景拓展到了数据中心甚至多数据中心级别的，通过虚拟化实现海量计算、网络、存储资源的细粒度管理，进而实现资源的有效聚合和弹性扩展。例如，互联网虚拟计算环境 iVCE\cite{Lu:2013:IVC:2388122.2388238}通过资源的“自主协同、按需聚合”，将静态统一视图的资源组织模式扩展为相对稳定视图、按需可伸缩的资源组织模式，从而实现面向互联网计算的高效管控。
 		\item 在应用软件的执行管控维度上，此类操作系统面向云服务这类大规模分布计算软件，提供了任务调度与执行、负载均衡、安全管控、在线监控和升级演化、分布式数据存储访问等一系列基础设施和相应能力。这些能力以的服务化方式提供，用户无需像传统系统软件那样自行安装、部署和维护。部分“平台即服务”基础设施还内建了编译系统和调测试环境，支持云端开发和编译构建。
-		\item 在可用性方面，此类操作系统需要 7×24小时持续提供基础服务，是支撑整个信息空间持续运行的核心基础设施。其突出表现为一旦发生故障，会产生较大的社会经济影响。例如，有文献指出如果一个主要的云平台宕机3－6天，美国经济会产生30亿－150亿美元的损失\footnote{"Cloud Down: Impacts on the US economy,"  https://www.lloyds.com/~/media/files/news-and-insight/risk-insight/2018/cloud-down/aircyberlloydspublic2018final.pdf}。
+		\item 在可用性方面，此类操作系统需要 7×24小时持续提供基础服务，是支撑整个信息空间持续运行的核心基础设施。其突出表现为一旦发生故障，会产生较大的社会经济影响。例如，有文献指出如果一个主要的云平台宕机3－6天，美国经济会产生30亿－150亿美元的损失\footnote{``Cloud Down: Impacts on the US economy,''  https://www.lloyds.com/~/media/files/news-and-insight/risk-insight/2018/cloud-down/aircyberlloydspublic2018final.pdf}。
 	\end{itemize}
 	
 	\item 智能终端操作系统
@@ -116,7 +116,7 @@
 60-70年代，编译系统的基础理论和相关技术也开始成熟。20世纪50年代，Noam Chomsky通过研究自然语言结构提出Chomsky文法类型，其中上下文无关文法成为现今几乎所有程序设计语言的语法\cite{chomsky1956three}。60年代至80年代，用于上下文无关文法识别的有效算法逐步发展为编译原理的标准部分，同时科学家们着眼研究编译器的自动构造，典型实例包括为UNIX操作系统研制的词法分析器生成工具Lex和语法分析器生成工具Yacc。编译系统中的代码优化研究也起步于这一阶段，包括与处理器体系结构无关的优化（如循环变换、常量传播、公共表达式删除）以及与处理器体系结构相关的优化（如寄存器分配、指令调度），后者与当时精简指令集、超标量、超长指令字等体系结构技术的发展密不可分。
 
 \subsection{多核/众核架构驱动的编译系统发展（21世纪-）}
-提高处理器性能是计算机领域长期追求的目标。随着处理器功耗、散热和设计复杂度等原因，在单核处理器上提高时钟频率的方法已无法继续提高处理器性能。因此，学术界和工业界开始改变策略，通过增加处理器核心数目来扩展性能。2001年，第一款商用非嵌入式多核处理器IBM POWER4发布，计算机体系结构发展进入多核时代。然而，增加处理器核数并不必然带来应用性能的提升，需要充分挖掘应用中的并行性以利用处理器的多核特性。在编译系统中挖掘并行性，具有对程序员透明、有可能在机器指令层面发挥硬件潜力等特点，因此当前的主流编译器（如GNU GCC、Intel ICC、IBM XLC和Oracle compiler）均提供了对多核心的支持和优化。
+提高处理器性能是计算机领域长期追求的目标。随着处理器功耗、散热和设计复杂度等原因，在单核处理器上提高时钟频率的方法已无法继续提高处理器性能。因此，学术界和工业界开始改变策略，通过增加处理器核心数目来扩展性能。2001年，第一款商用非嵌入式多核处理器IBM POWER4发布，计算机体系结构发展进入多核时代。然而，增加处理器核数并不必然带来应用性能的提升，需要充分挖掘应用中的并行性以利用处理器的多核特性。在编译系统中挖掘并行性，具有对程序员透明、有可能在机器指令层面发挥硬件潜力等特点，因此当前的主流编译器（如GNU GCC、Intel ICC、IBM XLC和Oracle Compiler）均提供了对多核心的支持和优化。
 
 与多核处理器通常仅集成几个处理单元不同，众核处理器在同一处理器内部集成了大量同构处理单元。例如，GPU（Graphics Processing Unit）在一个芯片上集成数百甚至数千个“小而简单”的核心，通过使用大量线程并发提高性能，特别适合用于加速大规模并行应用。近年来，众核处理器在高性能计算、人工智能等领域发展迅速，其编译优化技术也随着体系结构的不断升级而进步，包括针对GPU不同存储层次的优化、程序并行度的自动调优、通信优化、针对宽向量的自动向量化等。
 
@@ -204,6 +204,6 @@
 
 \begin{itemize}
 	\item 硬件技术和应用场景变迁是发展的核心动力。系统软件具有“承上启下”的特点，无论是形态还是机理的发展都受到硬件和应用两方面的驱动。例如，在贝尔定律支持下，计算设备约每10年一次换代，设备和用户增加10倍，成为新的蓝海、催生新型应用，间次推动操作系统换代并形成新的生态，使得操作系统每隔20年左右迎来一次跨越式发展的机遇期（参见图\ref{fig:3-1}）。另一个典型案例是编译系统：近年来高性能计算、智能计算方面的应用需求，以及GPU等新型硬件的出现，成为了编译系统近年来发展的主要动力。
-	\item 构建“抽象”和实现平台化是发展的重要主题。本质而言，系统软件负责向应用提供运行支撑、网络交互、数据管理等不同维度上的“抽象”（或者说虚拟机），并将这一“抽象”以尽可能高效方式绑定到硬件祼机，充分发挥硬件潜力。例如，过去数十年中，操作系统形成了一系列诸如文件、进程/线程、内存页、Socket等的概念，并由这些概念实体共同组成了应用可见的“抽象”（或者说虚拟机）。同时，沉淀共性、进而实现平台化也是系统软件发展的重要主题，一方面可以避免应用去重新“造每一个轮子”，另一方面也为软件生态奠定基础。
+	\item 构建“抽象”和实现平台化是发展的重要主题。本质而言，系统软件负责向应用提供运行支撑、网络交互、数据管理等不同维度上的“抽象”（或者说虚拟机），并将这一“抽象”以尽可能高效方式绑定到硬件裸机，充分发挥硬件潜力。例如，过去数十年中，操作系统形成了一系列诸如文件、进程/线程、内存页、Socket等的概念，并由这些概念实体共同组成了应用可见的“抽象”（或者说虚拟机）。同时，沉淀共性、进而实现平台化也是系统软件发展的重要主题，一方面可以避免应用去重新“造每一个轮子”，另一方面也为软件生态奠定基础。
 	\item 技术螺旋上升与交叉融合是发展的主要特征。与应用软件的快速更新不同，系统软件具有相对稳定性，很多核心技术表现出了螺旋上升的接入点。例如，虚拟化技术早在60年代IBM实验性操作系统CP-40和其后商用化的CP-67、VM/370中得到完整实现，而云计算时代虚拟化技术“复兴”过程中的挑战则主要来自于数据中心环境资源集约化的需求。另一方面，系统软件发展经历了从无到有、进而形成多个分支的过程。“分久必合”，近年来分支之间表现出相互融合趋势，中间件与操作系统就是一个典型案例（参见\ref{middleware}节）。
 \end{itemize}

Ch2-1-Overview.tex

@@ -40,7 +40,7 @@
 	
 	第三层含义是系统论。对于上述复杂软件系统，常常难以用其组成部件的性质去解释其整体性质。此时单纯依赖还原论方法难以驾驭其复杂性，需要借鉴系统论方法。
 	\subsubsection{系统观下的软件学科发展}
-	软件作为人类智力产品，无论是软件制品本身，还是软件开发、使用过程和场景都与万物和人类有着紧密关联，其开发和运行的网络化（网构软件的实践），以及软件基础设施化、服务化都触发了软件生产方式、计算平台和运行方式的变革。软件创新从个人、组织智慧发展到群体智慧创新。软件科学与自然科学、社会科学等各领域产生了千丝万缕的联系，信息物理融合、软件社会化、大数据时代的软件新形态使得软件必然成为技术-社会系统（Socio-Technical System）。人机物融合的软件系统，其复杂性本身就呈现在系统乃至系统之系统的层面上，综合性和系统性也愈来愈强。系统观要求软件科学体系需超越传统还原论的思维藩篱。
+	软件作为人类智力产品，无论是软件制品本身，还是软件开发、使用过程和场景都与万物和人类有着紧密关联，其开发和运行的网络化（网构软件的实践），以及软件基础设施化、服务化都触发了软件生产方式、计算平台和运行方式的变革。软件创新从个人、组织智慧发展到群体智慧创新。软件科学与自然科学、社会科学等各领域产生了千丝万缕的联系，信息物理融合、软件社会化、大数据时代的软件新形态使得软件必然成为技术-社会系统（Socio-technical System）。人机物融合的软件系统，其复杂性本身就呈现在系统乃至系统之系统的层面上，综合性和系统性也愈来愈强。系统观要求软件科学体系需超越传统还原论的思维藩篱。
 	
 	近年来，软件科学在系统观方向上进行了不少探索，包括：基于复杂网络来认识大规模软件系统的整体性质、基于多自主体的软件系统和方法、复杂自适应软件与系统、群体化软件开发方法等。网络化和大数据催发了融合软件系统与系统论研究的切入点，数据驱动的软件设计和优化初显端倪，在一些特定领域获得很大成功。人们对于数据驱动的软件的设计，不再遵循传统的自顶向下、分而治之、逐步精化的经典还原论法则，而是采用一种基于输入输出的黑盒的数据描述，训练出深度神经网络，充当所需要的软件。这种基于深度学习的方法从海量的样本中归纳出神经网络，其泛化能力可视为通过神经元系统的涌现而达成的功能。然而，这些研究仍处于方法层次，还未到达方法论的层次，即关于研究问题需要遵循的途径和研究路线，也可视作具体方法的元级层次。
 	
@@ -84,7 +84,7 @@
 	\subsection{价值观}
 	传统的软件质量观以软件制品为中心，人们主要通过客观度量软件系统来评估软件。新时代下，软件制品的内外部质量要求进一步强化和扩展。更重要的变化是，软件通过服务的方式满足用户需求，软件无迹可寻的趋势强化了软件作为人类价值载体的特征，需要在传统的质量观的基础上发展以人为中心的价值观。
 	\subsubsection{从质量走向价值}
-	传统的软件质量模型定义了内部质量、外部质量和使用质量，其主要关注包含内部质量和外部质量的系统质量。新时代下，软件生态和形态特征变化使得对于软件质量需要有新的认识。一方面变化是软件的服务化特征，即：软件系统通过服务满足用户需求，用户不再拥有软件制品，只享受软件提供的服务。软件服务可能由单一软件系统，或多个质量参差不齐的软件组合完成，因此，软件质量既针对单一软件系统，也针对软件系统的组合。另一方面，技术对社会的影响，使得软件体现了人类价值观。人类价值观，指的是“基于人的一定的思维感官之上而作出的认知、理解、判断或抉择，体现了人、事、物一定的价值或作用”，价值观具有稳定性、持久性、历史性和选择性等特点；软件通过一系列价值要素体现了主观的人类价值观，这些价值要素包括隐私性、安全性（safety \& security）、平等性等。传统的质量观转变为 “以软件制品为基础，以用户体验为中心”的价值观。在价值观主导下，不同用户会有不同的软件预期，也会使得同一软件系统具有不同的价值；软件系统体现的价值观，在人机物融合的发展背景下将作用于物理世界，影响物理世界的价值走向。
+	传统的软件质量模型定义了内部质量、外部质量和使用质量，其主要关注包含内部质量和外部质量的系统质量。新时代下，软件生态和形态特征变化使得对于软件质量需要有新的认识。一方面变化是软件的服务化特征，即：软件系统通过服务满足用户需求，用户不再拥有软件制品，只享受软件提供的服务。软件服务可能由单一软件系统，或多个质量参差不齐的软件组合完成，因此，软件质量既针对单一软件系统，也针对软件系统的组合。另一方面，技术对社会的影响，使得软件体现了人类价值观。人类价值观，指的是“基于人的一定的思维感官之上而作出的认知、理解、判断或抉择，体现了人、事、物一定的价值或作用”，价值观具有稳定性、持久性、历史性和选择性等特点；软件通过一系列价值要素体现了主观的人类价值观，这些价值要素包括隐私性、安全性（Safety \& Security）、平等性等。传统的质量观转变为 “以软件制品为基础，以用户体验为中心”的价值观。在价值观主导下，不同用户会有不同的软件预期，也会使得同一软件系统具有不同的价值；软件系统体现的价值观，在人机物融合的发展背景下将作用于物理世界，影响物理世界的价值走向。
 	\subsubsection{新时代软件系统的价值要素}
 	软件会有多个不同的角度来评价其价值。未来人机物融合的软件系统将在可信性、安全性、伦理观和持续性等价值要素上推动软件学科的发展。
 	
@@ -102,7 +102,7 @@
 	
 	（4）持续性
 	
-	软件系统成为支撑社会经济运行的基础设施，掌控了国民经济和社会关键基础资源，需具有持续提供服务的能力。软件系统提供服务的可持续性（sustainability），指的是在持续不间断运行、维护和发展过程中，面对各种突发异常事件，仍能提供令人满意的服务的能力。软件支撑的基础设施服务，为满足各类应用快速增长、新技术不断涌现的需求，需要具有开放扩展能力，即能集成各种异构的技术及系统，支持各类软件制品的即时加载/卸载，对内部状态及外部环境变化的感应、自主响应以及调控机制，以及个性化服务的定制等。显然，这种开放体系架构常常引入系统设计的脆弱性和质量隐患，从而给持续提供服务带来挑战。
+	软件系统成为支撑社会经济运行的基础设施，掌控了国民经济和社会关键基础资源，需具有持续提供服务的能力。软件系统提供服务的可持续性（Sustainability），指的是在持续不间断运行、维护和发展过程中，面对各种突发异常事件，仍能提供令人满意的服务的能力。软件支撑的基础设施服务，为满足各类应用快速增长、新技术不断涌现的需求，需要具有开放扩展能力，即能集成各种异构的技术及系统，支持各类软件制品的即时加载/卸载，对内部状态及外部环境变化的感应、自主响应以及调控机制，以及个性化服务的定制等。显然，这种开放体系架构常常引入系统设计的脆弱性和质量隐患，从而给持续提供服务带来挑战。
 	\subsubsection{价值观下，软件方法学的关键科学问题}
     新时代下，软件价值观不仅囊括传统的软件质量观，而且凸显了新时代下软件系统对物理世界的使能作用带来的影响，强调通过人的主体作用减少避免软件系统违反人类价值观。具体地，价值观强化了可信性、安全性、伦理观、持续性等具有新时代特色的价值要素，这些价值要素与软件开发运行维护过程的交融将经历一个长期的阶段，其带来的关键科学问包括四个方面：
 	

Ch2-3-SoftwareLanguage.tex

@@ -27,7 +27,7 @@
 \begin{itemize}
 	\item 特定领域语言一般是轻量的，是通用语言的特例。在通用语言的实现已经存在的前提下，我们可以用通用语言的方式来定义和实现领域特定语言。然而，这种方式不仅增加了开发的难度，而且也不经济。我们需要一种高效的特定语言的定义和实现方法。一个想法是设计并实现一种通用语言作为特定语言定义和实现的基础，但是什么样的通用语言适合于定义和实现各类特定领域语言是一个必须解决的问题。
 	\item 对于通用语言，我们已经开发了不少很有用的程序分析、优化、调试、测试方法。对于特定领域语言，我们需要利用这些方法。尽管我们可以用通用语言来实现某种特定领域语言，但是如何能够将这些一般性的方法系统化地映射到特定语言的实现上是一个挑战。比如，假设我们在通用语言上实现了一个测试方法，但是通用语言上的测试结果对于特定领域语言的用户而言是不能理解的。我们只有将通用语言上的测试例子和结果映射到特定语言程序上，特定领域语言的用户才能理解。
-	\item 在设计特定领域语言时存在的一个选择是应该设计一个小而精的语言，还是设计一个大而全面的语言？Schema语言的设计者之一的Guy Steele认为，既不应该建立一种小语言，也不应该建立一种大语言，而需要设计一种可以成长的语言。语言设计应该是增长式的——语言必须从小开始，能够随着用户集的增长而增长。例如，我们可以比较APL语言和Lisp语言：APL不允许用户以“流畅”的方式向该语言添加新的原语（premitive)，这使得用户难以扩展该语言；在Lisp中，用户可以定义与语言基元保持一致的单词，它使语言用户可以轻松扩展语言并共享代码。为此，在设计语言时，我们面临的挑战是，如何保证其具有一定的韧性，支持新的语言构造和特性可以被无缝接入其中，同时，在语言演化过程中，也能保证遗留系统被无障碍地执行。
+	\item 在设计特定领域语言时存在的一个选择是应该设计一个小而精的语言，还是设计一个大而全面的语言？Schema语言的设计者之一的Guy Steele认为，既不应该建立一种小语言，也不应该建立一种大语言，而需要设计一种可以成长的语言。语言设计应该是增长式的——语言必须从小开始，能够随着用户集的增长而增长。例如，我们可以比较APL语言和Lisp语言：APL不允许用户以“流畅”的方式向该语言添加新的原语（Premitive)，这使得用户难以扩展该语言；在Lisp中，用户可以定义与语言基元保持一致的单词，它使语言用户可以轻松扩展语言并共享代码。为此，在设计语言时，我们面临的挑战是，如何保证其具有一定的韧性，支持新的语言构造和特性可以被无缝接入其中，同时，在语言演化过程中，也能保证遗留系统被无障碍地执行。
 \end{itemize}
 \subsection{多范式程序设计的语言支持}\label{2_3_1_2}
 主流程序设计语言支持不同的程序设计范式\cite{ DBLP:journals/software/WamplerC10}。从程序设计语言的角度出发，一方面，需要设计与程序设计语言相适应的程序设计范式或者程序设计模型，以获取程序可读性、模块性、抽象性和性能上的平衡。另一方面，需要提供技术手段，根据程序员能力或者开发任务自动选择或者推荐程序设计范式，提升程序员程序设计效率。然而随着解决的问题越来越复杂，我们需要研究支持多范式的程序设计语言，以及对多范式语言的高效实现机制。特别是，我们面对下面一些挑战。

Ch2-4-DevelopmentMethodology.tex

@@ -73,7 +73,7 @@ DevOps 持续高效高质量的交付有赖于高度自动化支持工具的支
 微服务\index{微服务}化是支持前文提及的持续性要求的必备条件。软件系统的微服务化要求软件系统的各个模块或服务间的耦合进一步降低，从而在新版本发布或者部分服务出现问题时不会影响到系统其它部分。企业系统架构的微服务化以更好地支持DevOps已成为行业共识和趋势，然而在演化过程中却面临诸多挑战。首先，如何进行合理的服务划分，即将软件系统拆分成多个独立自治且协同合作的服务，是微服务应用实现敏捷、灵活和高可扩展的先决条件，也是微服务领域的一项严峻挑战。其次，虽然服务拆分为开发和维护提供诸多便利，但在另一方面，服务数量的增加也带来了系统整体测试复杂度的增长。例如，当采用微服务架构之后，系统对远程依赖项的依赖较多，而对进程内组件的依赖较少，因此测试策略和测试环境需要适应这种变化。微服务化的系统不仅需要保证组件内部的正确性，还需要通过契约测试等保证组件间通信和交互的正确性，使得众多微服务能够真正实现协同工作。相应地，微服务联调、日志分析与故障定位、自动化监控告警与治理策略等是当前以及未来较长时间内的研究中需要探索的迫切问题。此外，缺乏普遍适用的架构演化评估手段也是当前面临的挑战。微服务架构并不一定适合所有的企业情况，因此，在演化过程中，应该通过哪些角度去判断架构拆分的效果？如何建立这些角度与业务需求之间的对应关系？如何度量微服务拆分效果并及时给出建议（包括补充替代的架构形式）等都存在若干亟需解决的问题。
 
 \subsubsection{DevOps高频交付带来的质量和安全问题}
-质量和安全一直都不是新问题。然而，在DevOps语境下，在高水平自动化支持下的快速高频交付是维系持续性的基础，但同时也使得传统的质量和安全问题都有了新的含义和内容。例如，通过各类工具来实现自动化验证和确认是DevOps实践中的不二选择。然而，现有工具在发现并且消除缺陷和隐患的效率和效能方便并不完全令人满意，在快节奏和高度自动化的交付过程中，以往的交叉检验和人工分析等质量手段往往也被略去，不可避免地增加了很多质量风险。大量研究和实践表明，DevOps和Security合规往往在实践中处于天然对立关系，这种对立不是通过“构造”DevSecOps一个词汇能解决的。如何协调上述的对立是一个棘手问题。其次，现代软件系统的弱点（vulnerability）往往有多种来源和根本原因，例如来自上述基础设施的安全威胁、DevOps的快节奏所导致的各种妥协、质量缺陷、大量第三方组件的安全威胁、自动化运维中的安全隐患、企业文化（流程、人员技能和意识等）导致的安全疏漏等等。所谓百密一疏，尽管有一些工具、方法以及实践可以一定程度上缓解上述各种威胁带来的压力，但显然在效果和效率方面还有一些不足。从这个意义上说，退而求其次的方式是采取事后方式——通过监控系统运行过程尤其是通过分析系统异常来辅助发现安全风险。但是，这种方式还是有两大急需解决的难题，即1）如何产生可靠的高质量运行相关的数据（例如日志信息）以及2）如何应用先进的技术（例如大数据、AI技术等）提升对数据的利用效率和分析数据发现质量和安全性风险的能力。
+质量和安全一直都不是新问题。然而，在DevOps语境下，在高水平自动化支持下的快速高频交付是维系持续性的基础，但同时也使得传统的质量和安全问题都有了新的含义和内容。例如，通过各类工具来实现自动化验证和确认是DevOps实践中的不二选择。然而，现有工具在发现并且消除缺陷和隐患的效率和效能方便并不完全令人满意，在快节奏和高度自动化的交付过程中，以往的交叉检验和人工分析等质量手段往往也被略去，不可避免地增加了很多质量风险。大量研究和实践表明，DevOps和Security合规往往在实践中处于天然对立关系，这种对立不是通过“构造”DevSecOps一个词汇能解决的。如何协调上述的对立是一个棘手问题。其次，现代软件系统的弱点（Vulnerability）往往有多种来源和根本原因，例如来自上述基础设施的安全威胁、DevOps的快节奏所导致的各种妥协、质量缺陷、大量第三方组件的安全威胁、自动化运维中的安全隐患、企业文化（流程、人员技能和意识等）导致的安全疏漏等等。所谓百密一疏，尽管有一些工具、方法以及实践可以一定程度上缓解上述各种威胁带来的压力，但显然在效果和效率方面还有一些不足。从这个意义上说，退而求其次的方式是采取事后方式——通过监控系统运行过程尤其是通过分析系统异常来辅助发现安全风险。但是，这种方式还是有两大急需解决的难题，即1）如何产生可靠的高质量运行相关的数据（例如日志信息）以及2）如何应用先进的技术（例如大数据、AI技术等）提升对数据的利用效率和分析数据发现质量和安全性风险的能力。
 
 \subsubsection{智能化运维}
 作为DevOps中的Ops一端，运维的重要性越来越突显。工业界目前已经开始实践智能化运维（AIOps）技术以有效降低运维成本、提高运维效率和质量。我们注意到，随着各类AI技术和方法的迅速发展，智能化运维尽管已经有了较为坚实的基础，但是其有效实施却直接依赖于软件系统或者服务的运行时产生的各类数据和信息的质量。目前智能化运维主要提供一些相对简单的标准化日志信息的捕获、分析和决策；同时，当前的AIOps主要关注在运维一侧，尚未有效形成运维-开发的反馈闭环，以支持开发团队高效应对运维变化的新需求。此外，智能化运维依赖的各类数据和信息也都有各自缺点：日志数据的产生主要依赖程序员的个人经验，实践中往往日志实践开展的质量很差，导致大部分日志文件中充斥着毫无价值的垃圾信息，难以支持对软件行为的有效捕获；指标数据则是一种隔靴搔痒的环境数据，对错误定位的支持非常有限；跟踪路径数据会在瞬间产生巨量数据，导致完全无法分析。因此，如何充分使用这三类数据，在更加精细的力度上捕获软件应用或者服务的行为，进而提供更加准确的信息供分析，这是智能化运维需要解决的关键问题。