Xiaowu/20230511 (#794)

* update

* hhj

* update

* Update 17.2 智能化时代的软件工程.md

* update

* up

* update

* Update 可以吃的数据.md

* update

* update

* Update 17.4 深度学习平台质量问题实证研究.md

* up

基础教程/A3-深度学习最佳实践/10-基本概念/1.md

@@ -1,4 +0,0 @@
-梯度下降
-反向传播
-损失函数
-激活函数

基础教程/A5-现代软件工程（更新中）/README.md

@@ -27,7 +27,7 @@
 
 #### 感谢
 
-郭百宁、Lily Sun、程骉、韦青、邹欣、沈园、董航、陈洋、贺秋时、吴淞芮、强红军
+郭百宁、Lily Sun、程骉、韦青、邹欣、沈园、董航、陈洋、贺秋时、强红军
 
 
 

基础教程/A5-现代软件工程（更新中）/第5步 - 界面与交互/第9章 - 界面设计/可以吃的数据.md

@@ -0,0 +1,127 @@
+
+吃货的福音
+
+是否有人想过，当我们拿到一份“奇怪”的数据汇总时，我们需要将它......放进嘴里？研究人员对传统的数据可视化技术进行了创新，创造出一种可以吃的数据。或许在未来，这种可食用的数据将会对人类认知数据的习惯产生重要的影响。或许有一天，你的经理会对你说，“小张，明天中午各地子公司的代表会来总部做这个月的汇总报告，你跟我一起去吧。当他们把麻辣小龙虾和芝士蛋糕端出来的时候，你可千万得拉住我......”
+
+本小节摘录了来自微软亚洲研究院的一份有趣的研究报告，它描述了数据与食物的可比性，把“可视化”变成了“可食化”。
+
+中文标题：数据可食化—用食物表示数据
+原文标题：Data Edibilization:Representing Data with Food
+作者：Yun Wang, Xiaojuan Ma, Qiong Luo, Huamin Qu.
+原文链接: http://dl.acm.org/citation.cfm?id=2892570
+主要作者简介：
+
+王韵，微软亚洲研究院主管研究员，主要研究领域是人机交互、数据可视化、和人工智能。博士毕业于香港科技大学计算机科学与工程系，本科毕业于复旦大学软件学院，复旦大学大数据学院导师。其研究主要以增强人与数据的交互为目标——通过探索人工智能算法，人机协同的模式，和自然语言界面，提升人对数据的分析-理解-表达-创作的能力及效率。研究成果发表在 IEEE TVCG、IEEE VIS、ACM CHI、EuroVis 等顶级学术期刊和会议。担任 IEEE TVCG, ACM CHI, IEEE VIS 等顶级期刊与会议的审稿人。详细信息请访问：https://www.microsoft.com/en-us/research/people/wangyun/。
+
+### 问题
+
+在大数据时代的今天，我们每时每刻的行为数据都在被采集，收集，分析。数据分析让我们的世界变得更便捷，更智能，更美好。然而，对数据的研究往往止步于数据研究者科学家。作为数据的生产者，怎样才能更好地理解抽象而庞大的数据呢？
+
+<img src="img/food1.jpg"/>
+
+数据可视化是一个常用方法。通过将数据映射到简单的可视化图表，例如柱状图，树图，雷达图，平行坐标等等，人们可以更直观的理解数据的现状并预测未来的发展趋势。在此基础上，数据研究者专注于开发和研究更有效的映射技术与更完善的系统，进而分析更高维度，更复杂的数据。
+
+然而我们作为数据的生产者，除了采用可视化图表的形式，是否有一个更有效的渠道，让数据的理解和分析，自然地融入我们的生活？除了通过看可视化图表来体会数据的面貌，我们是不是还有可能吃到，尝到，闻到数据？
+
+### 方法
+
+为了让理解抽象而庞大的数据变得更生动，我们的“数据可食化”通过使用各种可以吃的食物原材料，来烹饪一道道美味的数据菜肴。让品尝美食，这原本就足够诱人的行为，变成一个更有趣、更丰富的体验。
+
+
+我们提出了两种制作数据美食的方法。一种数据美食来源于常见的菜肴本身，在此基础上对食物进行数据的映射，比如图中的果仁蛋糕，虽然外表形状相同，而其中干果的数量不同。当每只蛋糕中干果的数量与你的本月的收入或花费产生关联，一口咬下去，尝到的是满嘴蛋糕屑，还是满口果仁？它们都能客观地反映和理解这个月的你的生活状态。
+
+<img src="img/food2.jpg"/>
+
+
+
+
+另一种则是基于数据的特点，借鉴传统数据可视化来设计菜肴。比如可视化中的堆叠图，常常用来表示简单的数值数据。在此基础上设计的图中的意面，可以展现不同种类数据的比例。比如下图中，占了大面积的绿色的酸黄瓜，和略少面积的三文鱼，看起来是不是让人垂涎欲滴？这样的数据菜肴采用面积来，颜色，高度，来表示不同的类别，也是数据可视化领域中常用的方法，它能更精确地展现数据。
+
+<img src="img/food3.jpg"/>
+
+
+
+
+### 初期用户实验
+
+
+
+为了研究用户怎样通过数据菜肴感知数据，我们设计了三种数据菜肴，并将它们与常见的数据可食化一起呈现对比。我们邀请了15位参与者来参与我们的“数据品尝”讨论会，对他们进行观察，采访，并邀请他们填写李克特7级量表，并进行定性定量的实验和分析。
+
+
+<img src="img/food4.jpg"/>
+
+
+
+#### 1. 数据色拉
+
+
+
+第一个数据集是STEM专业每年不同学位者获得者的数量与工作机会的数量进行比较（数据来源于劳动统计局）。可视化的形式由柱形图表示。我们用一个田园色拉来表示该数据。在底部的面包屑对应于现有工作，咸火腿代表专科学位，甜玉米粒表示学士学位，切块番茄是硕士学位，芝麻菜象征的博士学位生。我们把这些材料按顺序叠置在透明的玻璃杯中，每种成分的量反映了数据值值。最终数据菜肴就像是一个还未混合的色拉。
+
+
+
+<img src="img/food5.jpg"/>
+
+
+#### 2. 芝士拼盘
+
+
+这个数据集的可视化形式使用一个饼图来展示。我们使用的数据是亚裔美国人对自己的认知，饼图的比例表示他们认为自己与典型的美国人“非常不同”，“非常相似”，或是“在此之间”。这道数据菜肴的外观与饼图的可视化图表类似，用不同颜色和风味的芝士颗粒，来映射百分比。白色是“非常相似“，橙色表示”非常不同“，而黄色表示在此之间。 
+
+<img src="img/food6.jpg"/>
+
+
+
+#### 3. 蘸酱饼干
+
+
+
+我们选用四个亚洲国家（中国、印度、日本、韩国）的农业就业率作为数据集。这个数据集的可视化和数据菜肴的呈现方式比较不同。我们用一个地理热力图的可视化来表示数据。而数据菜肴，我们则选用了四个国家最著名的蘸酱——用豆瓣酱表示中国，咖喱表示印度，芥末表示日本，泡菜辣酱表示韩国。在四块相同的饼干上放置不同的蘸酱，蘸酱的多少对应数据的大小。究竟对应了什么国家，就要靠我们的参与者亲口品尝。不同的蘸酱实际上是用口味和文化背景来暗示数据的类型。
+
+<img src="img/food7.jpg"/>
+
+
+### 实验分析
+
+
+
+我们的参与者提供了许多有价值的反馈，我们总结了发现数据可食化的以下特点：
+
+
+
+#### 1. 吸引力(Attractiveness)
+
+食物是人类赖以生存的基本，因此食物对大多数人有自然地吸引力。尤其是当你饥肠辘辘的时候，是想盯着电脑里的柱状图报表，还是来点数据意面？一位参与者（P15）表示，虽然芝士拼盘看起来并不那么华丽，但是对还没有吃午餐的自己来说，还是非常的吸引注意。
+
+#### 2. 感官上的丰富性(Sensory Richness)
+
+与二维屏幕上的图标相比，数据菜肴有更多感官上的丰富性。不仅仅可以用外观，颜色，形状，大小，也可以用香味，味道，质地，甚至吃起来的声音来表达数据。当我们的参与者们看到了数据色拉，上面的一片叶子引发了他们的激烈探讨，究竟是为什么要用一片叶子来代表博士生的数量？一位勇士大胆地卖出了这一步，首先尝了尝，啊，原来这片生菜叶是苦的！大家这才恍然大悟。
+
+
+<img src="img/food8.jpg"/>
+
+
+#### 3. 更深的内涵(Intangible Richness)
+
+除了感官上的丰富性，不同的食物也有不同的文化内涵。比如用不同酱料来表达不同的地域——看到老干妈豆瓣酱，大家自然地想到了中国。一位来自泰国的参与者（P11）表示，这些酱料都很有特色，不过如果我尝到了来自我们泰国的酱料，大概会觉得更有趣更有共鸣！
+
+
+#### 4. 记忆(Memorability)
+
+我们的实验参与者都表示，对比起可视化图表，通过食物来表达数据，可以让他们更好的记住数据。当数据菜肴呈现在你面前，飘来或浓或淡的香气，能激发大家的想象，也能让大家对数据的记忆更深刻。数据菜肴如用在教育业，可能会大幅度提高对儿童青少年的学习兴趣和对知识的记忆；如用于营销展览，也可能给人们留下深刻的印象。
+
+
+<img src="img/food9.jpg"/>
+
+#### 5. 感情性(Affectiveness)
+
+过去的研究表明，食物本身具备一些表达感情的作用。总体而言，人们对食物有更多的正向的情感。而香味和味道，也自然地对应不同的情绪。比如，人们会称呼爱人为“甜心”，或用酸、甜、苦、辣来表示心情。另外，吃东西的动作也似乎有更深刻的内涵。我们的一个参与者（P8）想象，假如我吃下我的过去一学年的成绩数据，就好像能感觉到我在接受、理解和消化我过去或好或坏的成果，并且会吸收其中的营养，进而成长和更好地展望未来。
+
+#### 6. 社交性(Sociability)
+
+从东方到西方，饮食都是一个传统的社交方式。会议中的茶歇，恋人的约会，亲友的聚会，都离不开食物。数据可食化自然地将数据引入到了人们的社交生活中，成为大家社交生活中谈论的话题。参与者（P5）说：我们聚在一起，尝试着吃这些新奇的食物，猜测、讨论、甚至争论数据是怎么被显性或隐性表达，这真是一项充满乐趣的活动。
+
+<img src="img/food10.jpg"/>
+
+数据可食化的研究正在它的初期，我们实验中的案例和数据映射也较为简单，然而我们还是能想象到它广阔的应用场景，譬如娱乐，教育，健康等产业。同时，数据可食化也面临一些新的挑战，比如食物文化背景的差异，人与人敏感度的差异，食物保存和营养健康方面的考量等等。但是我们仍然相信，随着技术的发展，比如物联网，智能食物生产，大数据菜谱生成，3D食物打印，这些技术的不断成熟能帮助我们克服上述挑战，将生活中产生的数据和我们的生活本身更紧密地关联起来，让我们能更好地获取、理解和消化数据。未来的我们也许再也不用看着手机吃饭。而是一边吃饭，一边细细品尝，咀嚼，体会，探讨我们自己所生成的数据，以及用数据描绘的我们的世界。

基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第12章 - 技术架构/12.3 星形系统架构模式.md

@@ -4,7 +4,7 @@
 
 这是一种最传统、最基本的模式，简称为 C/S，是其它一切模式的基础。见图 12.3.1。
 
-<img src='img/Slide8.svg'>
+<img src='img/Slide8.SVG'>
 
 图 12.3.1 客户端-服务器模式
 
@@ -61,7 +61,7 @@
 
 此模式简称为 B/S，从 C/S 模式发展而来。见图 12.3.2。
 
-<img src='img/Slide9.svg'>
+<img src='img/Slide9.SVG'>
 
 图 12.3.2 浏览器-服务器模式
 
@@ -102,7 +102,7 @@
 
 这是客户端-服务器模式的双向扩展。见图 12.3.3。
 
-<img src='img/Slide10.svg'>
+<img src='img/Slide10.SVG'>
 
 图 12.3.3 对等模式
 

基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第12章 - 技术架构/12.4 串行系统架构模式.md

@@ -5,7 +5,7 @@
 
 见图 12.4.1。
 
-<img src='img/Slide11.svg'>
+<img src='img/Slide11.SVG'>
 
 图 12.4.1 管道-过滤器模式
 
@@ -55,7 +55,7 @@ cat a.txt | grep 'food' | sort | uniq > out
 
 见图 12.4.2。
 
-<img src='img/Slide12.svg'>
+<img src='img/Slide12.SVG'>
 
 图 12.4.2 分层模式
 
@@ -118,7 +118,7 @@ cat a.txt | grep 'food' | sort | uniq > out
 
 因为 Slave 这个词比较敏感，因此英文中更多地使用 Primary-Secondary，我们只要知道 Slave 不是“奴隶”的意思就好。见图 12.4.3。
 
-<img src='img/Slide13.svg'>
+<img src='img/Slide13.SVG'>
 
 图 12.4.3 主从模式
 

基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第12章 - 技术架构/12.5 树形系统架构模式.md

@@ -19,7 +19,7 @@
 
 还有一种叫做 Delegate 即“委托性代理”的概念，它只涉及两个方面的角色，即委托人和被委托人，没有第三方，所以不符合本节中的“代理”概念。
 
-<img src='img/Slide14.svg'>
+<img src='img/Slide14.SVG'>
 
 图 12.5.1 代理模式
 
@@ -94,7 +94,7 @@ DNS 就属于第一种方式，但是并不是典型的代理模式。
 
 当将应用程序作为一组微服务编写时，实际上就是在编写可以协同工作的多个应用程序。其中每个微服务都有自己的职责，每个开发团队都可以独立于其他微服务进行开发。这些微服务之间唯一的依赖就是通信。当微服务彼此通信时，必须确保它们之间发送的消息能够向后兼容（因为微服务可以很快地升级）。
 
-<img src='img/Slide15.svg'>
+<img src='img/Slide15.SVG'>
 
 图 12.5.2 微服务模式
 
@@ -193,7 +193,7 @@ DNS 就属于第一种方式，但是并不是典型的代理模式。
 
 见图 12.5.3。
 
-<img src='img/Slide16.svg'>
+<img src='img/Slide16.SVG'>
 
 
 #### 应用场景

基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第12章 - 技术架构/12.6 环形系统架构模式.md

@@ -26,7 +26,7 @@ MVC 模式通过将内部信息表示、用户信息呈现以及用户操作接
 
 见图 12.6.1。
 
-<img src='img/Slide17.svg'>
+<img src='img/Slide17.SVG'>
 
 图 12.6.1 MVC 架构
 
@@ -88,7 +88,7 @@ MVC使开发和维护用户接口的技术含量降低。使用MVC模式使开
 
 见图 12.6.2。
 
-<img src='img/Slide18.svg'>
+<img src='img/Slide18.SVG'>
 
 图 12.6.2 反馈模式
 
@@ -150,7 +150,7 @@ MVC使开发和维护用户接口的技术含量降低。使用MVC模式使开
 
 见图 12.6.3 拓扑结构。
 
-<img src='img/Slide19.svg'>
+<img src='img/Slide19.SVG'>
 
 图 12.6.3 事件驱动模式
 

基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.0 前沿探索.md

@@ -1,16 +1,13 @@
 # 第十七章 前沿探索
 
-本章中的 17.1 和 17.2 两个小节，各自是一篇文章，是复旦大学计算机科学技术学院副院长彭鑫教授在微信公众号 CodeWisdom 发布的，笔者征得彭教授的同意后摘抄下来的。在此特别感谢彭教授的支持！
 
-以下是 CodeWisdom.net 的自我介绍（原文为英文），希望对现代软件工程感兴趣的读者给与关注：
+本章中的 17.1 和 17.2 两个小节内容转载自复旦大学计算机科学技术学院副院长彭鑫教授及其团队所创办的 CodeWisdom 公众号，讲述了大模型对软件工程的影响。17.3 节内容转自微软亚洲研究院王韵等人的一篇关于新冠疫情期间混合办公模式的调研，笔者认为这种模式同样适合于疫情之后。17.4 节内容转自微软亚洲研究院高彦杰等人的一篇关于深度学习平台质量问题的调研。
 
-*CodeWisdom 是中国复旦大学的软件工程研究团队。我们的研究兴趣主要集中在人工智能的软件工程方法和工具（即 AI4SE 和 SE4AI）。在 AI4SE 的方向上，我们正在探索使用人工智能技术进行软件开发、维护和运营的数据驱动软件工程技术和工具，包括：软件分析和大数据分析，以提高软件开发质量和效率；使用深度学习和知识图谱等人工智能技术进行智能代码推荐和软件开发问答；云原生（微服务）架构和 AIOps（用于 IT 运营的人工智能）。在 SE4AI 的方向上，我们正在探索人工智能应用程序的开发、维护和运营所需的软件工程技术和软件基础设施，包括：泛在计算的软件基础设施和敏捷应用程序开发；用于机器人和机器人程序的测试/调试/操作的程序合成；用于机器学习和基于深度学习的应用程序的软件开发、测试、维护和操作方法。我们的作品获得了 ICSM 2011 最佳论文奖、ASE 2018/2021 ACM SIGSOFT 杰出论文奖、ICSME 2018/2019/2020 IEEE TCSE 杰出论文奖和 IEEE 软件工程汇刊 2018 最佳论文奖。除了发表论文，我们还与领先的 IT 和互联网公司密切合作。与此同时，我们正在基于我们的研究开发软件系统和工具。该网站提供我们正在开发的一些软件系统和工具的演示和在线服务。欢迎对我们的系统和工具提出任何建议和反馈。*
-
-### 作者简介
-
-彭鑫，复旦大学计算机科学技术学院副院长、教授，中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，IEEE 高级会员，《Journal of Software: Evolution and Process》联合主编，《ACM Transactions on Software Engineering and Methodology》编委，《软件学报》编委，《Empirical Software Engineering》编委。主要研究方向包括软件智能化开发与运维、人机物融合泛在计算、机器人软件工程等。
 
 ### 参考资料
 
-- 《浅评ChatGPT在软件开发上的辅助能力》，彭鑫，CodeWisdom 微信公众号
-- 《智能化时代的软件工程》，彭鑫，CodeWisdom 微信公众号
+- 《浅评ChatGPT在软件开发上的辅助能力（附GPT-4对比）》，复旦大学 CodeWisdom 团队：杜雪盈、字千成、刘俊伟、彭鑫、娄一翎、刘名威
+- 《智能化时代的软件工程》，复旦大学 彭鑫，CodeWisdom 微信公众号
+- Returning to the Office During the COVID-19 Pandemic Recovery: Early Indicators from China，王韵 等，https://dl.acm.org/doi/10.1145/3411763.3451685
+
+- An Empirical Study on Quality Issues of Deep Learning Platform，高彦杰 等，https://www.microsoft.com/en-us/research/publication/an-empirical-study-on-quality-issues-of-deep-learning-platform/

基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.1 GPT大模型软件开发辅助.md

@@ -1,9 +1,15 @@
 
 ## 17.1 浅评 ChatGPT 在软件开发上的辅助能力
 
+本文转载自 CodeWisdom 公众号文章《浅评ChatGPT在软件开发上的辅助能力（附GPT-4对比）》，作者为复旦大学CodeWisdom团队的杜雪盈、字千成、刘俊伟三位研究生及彭鑫、娄一翎、刘名威三位老师。
+
+团队简介：
+
+CodeWisdom 是中国复旦大学的软件工程研究团队。我们的研究兴趣主要集中在人工智能的软件工程方法和工具（即 AI4SE 和 SE4AI）。在 AI4SE 的方向上，我们正在探索使用人工智能技术进行软件开发、维护和运营的数据驱动软件工程技术和工具，包括：软件分析和大数据分析，以提高软件开发质量和效率；使用深度学习和知识图谱等人工智能技术进行智能代码推荐和软件开发问答；云原生（微服务）架构和 AIOps（用于 IT 运营的人工智能）。在 SE4AI 的方向上，我们正在探索人工智能应用程序的开发、维护和运营所需的软件工程技术和软件基础设施，包括：泛在计算的软件基础设施和敏捷应用程序开发；用于机器人和机器人程序的测试/调试/操作的程序合成；用于机器学习和基于深度学习的应用程序的软件开发、测试、维护和操作方法。我们的作品获得了 ICSM 2011 最佳论文奖、ASE 2018/2021 ACM SIGSOFT 杰出论文奖、ICSME 2018/2019/2020 IEEE TCSE 杰出论文奖和 IEEE 软件工程汇刊 2018 最佳论文奖。除了发表论文，我们还与领先的 IT 和互联网公司密切合作。与此同时，我们正在基于我们的研究开发软件系统和工具。该网站提供我们正在开发的一些软件系统和工具的演示和在线服务。欢迎对我们的系统和工具提出任何建议和反馈。
+
 笔者对于原文的修改有以下几处：
 
-- 原文中 GPT 的回答是用截图方式展示的（图片分辨率较低），笔者使用 OCR 软件把截图转变成文字。
+- 原文中 GPT 的回答是用截图方式展示的（图片分辨率较低），笔者使用 OCR (ocr.space) 软件把截图转变成文字。
 - 修改了部分章节编号以便于排版阅读，顺序不变，并不影响原文思想。
 - 由于篇幅有限，省略了 ChatGPT3.5 部分，有兴趣的读者可以阅读原文。
 - 由于篇幅有限，在后面的代码部分省略了一些环节，有兴趣的读者可以阅读原文。

基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.2 智能化时代的软件工程.md

@@ -1,44 +1,45 @@
 ## 17.2 智能化时代的软件工程
 
+本文转载自 CodeWisdom 公众号文章《智能化时代的软件工程：拥抱大模型的正确姿势》，作者为复旦大学彭鑫教授。总结了 ChatGPT 对于软件工程领域的影响。
+
+作者简介：
+
+彭鑫，复旦大学计算机科学技术学院副院长、教授，中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，IEEE 高级会员，《Journal of Software: Evolution and Process》联合主编，《ACM Transactions on Software Engineering and Methodology》编委，《软件学报》编委，《Empirical Software Engineering》编委。主要研究方向包括软件智能化开发与运维、人机物融合泛在计算、机器人软件工程等。
+
+### 摘要
+
 以 ChatGPT 为代表的大模型技术对于包括软件工程在内的很多领域都带来了巨大的冲击，也引发了广泛的焦虑。为了在迷雾中看清一点方向，近期我们基于各种技术文献和实践分享以及我们自身的一些初步探索不断地在讨论和思考“大模型时代的软件工程”这一命题。同时我也参加了几次线上访谈，触发了我更多的一些认识和思考，在此基础上撰写了这篇文章，希望与大家分享并倾听大家的意见。由于到目前为止大模型在很大程度上仍然是一个黑盒，并且大模型技术还在快速迭代和发展之中，同时目前看到的以及我们自己实践的基于大模型的软件开发案例还比较初步，因此本文的很多认识和思考不一定准确，未来还可能会随着技术和实践的发展而不断刷新。
 
 ### 17.2.1 大模型冲击波
 
- ChatGPT（基于GPT3.5）的热潮还未褪去，GPT4 又横空出世，所带来的冲击是全领域、全方位的。在软件工程领域，学术界和工业界都被大模型在软件开发方面的全方位能力所震撼。一些技术专家纷纷上手体验，通过与大模型对话完成需求分析、软件设计、代码实现、软件测试、代码重构、缺陷检查与修复等各种开发任务，甚至尝试用大模型实现端到端的软件应用开发。其结果自然是震撼式的，以至于很多人惊呼“编程要被终结了”、“程序员要大批下岗了”。随之而来的是各种“软件工程新时代即将到来”的论断，有人称之为“软件工程3.0”，有人称之为“软件2.0”，意思都是软件开发要迈入全面智能化的新时代了。
-
+ChatGPT（基于GPT3.5）的热潮还未褪去，GPT4 又横空出世，所带来的冲击是全领域、全方位的。在软件工程领域，学术界和工业界都被大模型在软件开发方面的全方位能力所震撼。一些技术专家纷纷上手体验，通过与大模型对话完成需求分析、软件设计、代码实现、软件测试、代码重构、缺陷检查与修复等各种开发任务，甚至尝试用大模型实现端到端的软件应用开发。其结果自然是震撼式的，以至于很多人惊呼“编程要被终结了”、“程序员要大批下岗了”。随之而来的是各种“软件工程新时代即将到来”的论断，有人称之为“软件工程3.0”，有人称之为“软件2.0”，意思都是软件开发要迈入全面智能化的新时代了。
 
 大模型在软件开发方面强大的能力应该已经是毋庸置疑了，它对于软件开发的颠覆性影响应该也可以预见，也就是说大模型助推软件开发进入新的智能化时代应该是可以确定的了。但我们不清楚的是这样的一种新时代会是什么样的，在可见的未来软件开发模式将会发生什么样的变化，有哪些开发岗位会消失又有哪些新的开发岗位会出现？无论学术界还是工业界，很多人都很迷茫和焦虑，因为看不清楚前面的道路。例如，前哈佛大学计算机科学教授、谷歌工程主管 Matt Welsh预测生成式AI将在3年内终结编程，到那时候软件开发团队中只有两类人会保留，即产品经理和代码评审人员。如果他的预测成真，那么当前软件工程领域的很多研究方向以及相关的工作岗位都不需要了，例如软件架构和软件维护。
 
 
 ### 17.2.2 冷静思考
 
-
- ChatGPT 包括基于 GPT4 的版本）作为一种智能化工具在软件开发的各个环节发挥显著作用已经是一种既成现实了。这让我想起了20年前所研究的软件复用和软件产品线：通过代码复制粘贴和API调用广泛实现局部复用并不难，难的是通过需求和设计规划实现系统性的定制化产品开发（例如软件产品线所宣称的那样）。与之相似，利用 ChatGPT 在软件开发过程中广泛实现局部的智能化辅助支持（例如代码片段生成和技术问答）并不困难，难点在于如何利用它们实现端到端、系统性的生成式开发。
-
-
-在这个方面，一些业界专家已经做了一些探索并在各种公众号上分享了自己的体验。从这些探索可以看到，对于俄罗斯方块、贪吃蛇这类常见的小规模软件应用 ChatGPT 可以在适当的引导下通过自然语言对话逐步生成完整的可执行程序，产生的代码质量也比较高。由此带来的问题是，这种端到端的生成式软件开发能力能否推及规模更大、复杂度更高的企业软件项目中？这让我想起了Brooks在他的经典著作《No Silver Bullet-Essence and Accident in Software Engineering》中对于软件开发的根本性（Essence）困难和偶然性（Accident）困难的论述：根本性的困难在于对于构成抽象软件实体的复杂概念结构的构思，而产生这种抽象软件实体的编程语言表示只是偶然性的困难。软件工程过去几十年所取得的进展大多在于偶然性的困难方面，而在根本性困难（主要集中在需求和设计）方面则进展不大。
+ChatGPT 包括基于 GPT4 的版本）作为一种智能化工具在软件开发的各个环节发挥显著作用已经是一种既成现实了。这让我想起了 20 年前所研究的软件复用和软件产品线：通过代码复制粘贴和 API 调用广泛实现局部复用并不难，难的是通过需求和设计规划实现系统性的定制化产品开发（例如软件产品线所宣称的那样）。与之相似，利用 ChatGPT 在软件开发过程中广泛实现局部的智能化辅助支持（例如代码片段生成和技术问答）并不困难，难点在于如何利用它们实现端到端、系统性的生成式开发。
 
 
+在这个方面，一些业界专家已经做了一些探索并在各种公众号上分享了自己的体验。从这些探索可以看到，对于俄罗斯方块、贪吃蛇这类常见的小规模软件应用 ChatGPT 可以在适当的引导下通过自然语言对话逐步生成完整的可执行程序，产生的代码质量也比较高。由此带来的问题是，这种端到端的生成式软件开发能力能否推及规模更大、复杂度更高的企业软件项目中？这让我想起了 Brooks 在他的经典著作《No Silver Bullet-Essence and Accident in Software Engineering》中对于软件开发的根本性（Essence）困难和偶然性（Accident）困难的论述：根本性的困难在于对于构成抽象软件实体的复杂概念结构的构思，而产生这种抽象软件实体的编程语言表示只是偶然性的困难。软件工程过去几十年所取得的进展大多在于偶然性的困难方面，而在根本性困难（主要集中在需求和设计）方面则进展不大。
 
 端到端的生成式软件开发显然需要逾越需求分析和软件设计这两座大山，那么 ChatGPT 在这两个方面的能力如何呢？从目前分享的端到端生成式软件开发案例来看，似乎 ChatGPT 已经具有一定的分析和设计能力，具体表现在：
 
 - 根据给定的高层需求自动生成细化需求，还可以进行条目整理；
-- 根据要求自动生成需求描述的规范化表示，例如UML顺序图；
+- 根据要求自动生成需求描述的规范化表示，例如 UML 顺序图；
 - 根据需求自动生成包含多个类的设计结构；
 - 根据开发人员的提示以一种增量的方式逐步生成应用代码（这要求对原有的代码实现结构有理解）；
 - 根据一般的设计原则对代码进行自动化重构以提高可理解性和可扩展性。
-- 根据需求自动生成数据库表结构设计以及相应的建表SQL语句；
-
-
+- 根据需求自动生成数据库表结构设计以及相应的建表 SQL 语句；
+......
 
 那么 ChatGPT 真的会做分析和设计吗？从目前各路专家分享的实践经验看，不能说它不会，但所尝试的软件应用规模较小（例如百行到千行代码），需求较简单（例如俄罗斯方块游戏、图书馆管理等简单信息系统）甚至网上存在大量同类应用的代码和文档。此外，要想通过对话式的过程让 ChatGPT 端到端地生成完整代码，开发人员需要具有很强的对话和引导能力，不断能清晰表达要求而且还要能将开发要求分解为一系列要求明确的任务并按照合理的顺序引导 ChatGPT 完成。例如，在张刚的分享《ChatGPT 结对编程实录：提升生产力，还是被代替？》中，一个简单的俄罗斯方块游戏的实现过程被拆分为了10个任务，分别是：创建游戏框架、使用GUI替换控制台、在GUI上显示一个L形方块、移动方块并且进行碰撞检测、旋转方块、落下方块并且创建一个新的方块、检测游戏结束、增加整行消除功能、加入所有类型的方块、增加计分能力。这个任务拆解体现了一个非常合理的增量和迭代开发过程，后面的任务依赖于前面的任务，同时每一个任务完成后效果都可以确认（例如程序可运行）。虽然这个任务拆解过程也受到了 ChatGPT 输出的启发，但仍然需要开发人员掌握整体的迭代过程，而且其中还融入了一定的设计思考。此外，开发人员还需要不断检查 ChatGPT 产生的结果，及时发现 ChatGPT 的错误并提醒修正。特别是在需求分析过程中，ChatGPT  进行需求细化主要依据常识或某类软件的共性特征，可能遗漏一些重要需求，同时创新性或个性化需求也需要开发人员进行补充。
 
 我们再从大模型的训练方式以及软件开发的本质性问题出发进行一下思考。以下几点是我目前得到的一些认识。
 
-
 #### 1. 软件开发的规模和复杂性可能会从人机两个方面限制大模型的能力
 
-
 首先，生成式的开发过程高度依赖于开发人员对于大模型的分步引导，这就要求开发人员自身能够完整和深入掌握整个软件的设计和实现过程，这样才能以合理的方式进行任务拆解并按照合理的顺序引导大模型逐步生成代码。当一个软件的规模达到几万、几十万甚至几百万行代码时，人的大脑可能已经无法掌控整个代码生成过程了。而且对于大规模复杂软件系统而言，任务的拆解和实现并不是一个串行的过程，而是存在很多条平行的线索并伴随着不断的分叉与合并。因此，在传统的软件开发中，开发人员需要对大规模复杂系统进行多层拆解，不同的开发小组和个人分别负责不同层次和不同部分的工作，同时开发团队根据需要随时进行沟通协调和设计方案调整。这一过程目前还很难被大模型所取代。其次，大模型本身对于复杂系统开发过程的全局掌握能力也是有限的。例如，我们团队的分享《浅评 ChatGPT 在软件开发上的辅助能力（附GPT-4对比）》中提到，即使是在规模很小的软件的生成过程中，ChatGPT  也可能会“遗忘”之前生成的代码（例如方法名、方法返回值前后不一致）。这导致大模型可能会顾此失彼，难以生成大规模的软件实现代码。最后，人工代码审核的存在使得软件设计和代码质量仍然有着重要的意义。即使目前最乐观的估计也承认大模型生成的代码仍然需要人工审核。如此一来，对于大规模软件系统而言，模块化、信息隐藏、关注点分离、代码可理解性等原则仍然十分重要，否则审核代码的开发人员将难以理解大模型生成的代码并成为软件开发过程中的瓶颈。
 
 #### 2. 大模型可能缺少抽象思维能力同时在精确性上存在不足
@@ -53,8 +54,6 @@
 
 企业软件系统一般都有着很长的生存周期，在此期间可能由于多种原因（如需求变更、使用环境变化、缺陷修复、性能提升等）进行修改，同时也可能会面向不同客户进行定制。这些软件维护和演化过程中蕴含着很多软件工程问题和挑战。要实现系统的软件智能化开发支持，大模型显然不能只做一锤子买卖（即只负责最初的代码生成）而需要在长期的软件维护和演化过程中根据需要完成各种功能扩展和代码修改任务。这要求大模型能够理解代码中业已实现的各种需求、设计方案以及需求/设计元素与代码元素之间的精确对应关系，同时需要知晓并处理代码修改与各个部分之间的交互关系（如修改带来的直接或间接影响）。此外，大模型生成的代码本身可能存在很多重复的地方，这些重复代码（代码克隆）的长期维护特别是一致性修改可能成为一种负担。
 
-
-
 ### 17.2.3 拥抱大模型的正确姿势
 
 大模型在一些编程任务上的优异表现让很多人感到很兴奋，同时也对大模型颠覆软件工程、实现全面的生成式软件开发的前景感到很乐观。但我觉得，要谈大模型的软件开发能力首先要区分所开发的软件类型。对于小规模的软件应用，甚至适合最终用户编程（End User Programming）的应用开发任务，利用大模型实现端到端的完整代码生成是完全可能的。而对于大规模的复杂软件系统而言，根据需求陈述实现端到端的完整代码生成还不太现实。
@@ -65,17 +64,14 @@
 
 软件开发为很多不同的行业提供数字化解决方案，然而软件开发自身的数字化程度却很低。例如，通用软件资产（如公共组件）未得到有效整理和复用，重新发明轮子（如重复实现相同的功能）的现象十分普遍；每次代码修改的前因后果不清楚，例如引发代码修改的开发任务（如特性实现或缺陷修复）以及代码修改所带来的影响（如引入代码问题以及度量指标的变化）缺少系统化的记录。此外，软件中所蕴含的需求和设计知识缺少明确的描述以及与代码的清晰映射关系，导致开发人员经常就相同的问题重复思考。在这种情况下奢望大模型直接带来跨越性的全面智能化开发体验可能是不切实际的。正确的做法可能是扎实做好软件开发的数字化和知识化积累，在此基础上再与大模型结合实现更系统的智能化开发支持。例如，构建特定领域的通用组件库并建立描述体系，建立软件代码克隆以及软件供应链的全面跟踪和管理体系，建立开发任务（特性实现、缺陷修复等）、开发人员、代码提交和修改内容之间的追踪关系，建立并维护高层设计描述及其与代码单元之间的映射关系。这些数字化和知识化建设本身就可以提高软件开发质量和效率。而大模型不仅可以为软件开发的数字化和知识化提供技术和业务背景知识，而且还为我们整合数字化和知识化平台中的信息和知识提供了一种有力的手段。
 
-
 #### 2. 更加重视需求、设计、验证等软件工程基本能力建设
 
 我比较认同 Bertrand Meyer 在《Communications of the ACM》的一篇博客文章中所提到的观点，即： ChatGPT 这类大模型并不会带来编程的终结，而是会复兴软件工程领域的一些根本性的技术，例如需求分析、精确的规格说明以及软件验证（包括动态测试和静态分析）。这些软件工程传统技术有望在大模型时代重新焕发青春，但可能需要考虑如何与数据驱动的大模型技术有机结合。同时，如前所述，也需要加强需求、设计、测试等方面的数字化和知识化基础设施建设。
 
-
 #### 3. 探索能有效整合大模型、开发人员以及各种工具能力的智能交互引擎
 
-我们当前在软件开发领域所面临的局面与Gartner近几年力推的超级自动化（Hyperautomation）所针对的问题很像，也就是存在很多自动化工具系统（如调试与测试工具、编译构建工具、代码静态检查工具等）同时形成了丰富的资源库和过程库（如通用组件库、开源代码仓库、软件开发在线问答系统、缺陷跟踪系统、版本管理系统等），但面临的问题是如何在人工智能技术的支持下将这些自动化能力和资源无缝衔接构成全过程的智能化体验。对于软件开发而言，还有一个重要的问题是如何将人（开发人员）和机（大模型及各种工具）的能力有机融合、实现高效的人机协同。如前所述，大模型在生成式软件开发过程中所发挥的作用与人的交互和引导能力密切相关，同时人的经验在高层决策以及代码审核等环节还要发挥重要作用。因此，系统性的智能化开发过程不能完全依赖于开发人员自身与大模型的交互能力，而是应该追求建立一种能够统一调度并有效整合大模型、开发人员以及各种工具能力的智能交互引擎。例如，依托下一代IDE形成的开发人员统一门户可以通过一个智能交互引擎理解当前的开发任务及进展态势，在基础上灵活调度和利用大模型的生成能力（如细化一段需求或生成一段代码）、已有的数字化信息和知识积累（如代码依赖关系、通用组件、软件设计决策等）、各种工具能力（如运行代码静态检查或自动化测试、查询相关的缺陷报告信息以及提交新的缺陷报告等）以及开发人员的主观判断（如作出需求和设计决策、审核大模型产生的结果等）。这一过程的一个突出特点是智能交互引擎主导，将开发人员的经验判断与各种工具的能力以及大模型的智能有机结合，并实现高度顺畅的智能化和自动化开发过程。此外，智能交互引擎还需要实现开发人员与大模型之间的人机交互过程的会话管理，支持以“多线程”的方式与大模型开展交互式探索同时支持这些探索线索的按需拆分（fork）和归并（join）。在此过程中，智能交互引擎需要做好会话状态和上下文的管理和切换。
+我们当前在软件开发领域所面临的局面与 Gartner 近几年力推的超级自动化（Hyperautomation）所针对的问题很像，也就是存在很多自动化工具系统（如调试与测试工具、编译构建工具、代码静态检查工具等）同时形成了丰富的资源库和过程库（如通用组件库、开源代码仓库、软件开发在线问答系统、缺陷跟踪系统、版本管理系统等），但面临的问题是如何在人工智能技术的支持下将这些自动化能力和资源无缝衔接构成全过程的智能化体验。对于软件开发而言，还有一个重要的问题是如何将人（开发人员）和机（大模型及各种工具）的能力有机融合、实现高效的人机协同。如前所述，大模型在生成式软件开发过程中所发挥的作用与人的交互和引导能力密切相关，同时人的经验在高层决策以及代码审核等环节还要发挥重要作用。因此，系统性的智能化开发过程不能完全依赖于开发人员自身与大模型的交互能力，而是应该追求建立一种能够统一调度并有效整合大模型、开发人员以及各种工具能力的智能交互引擎。例如，依托下一代 IDE 形成的开发人员统一门户可以通过一个智能交互引擎理解当前的开发任务及进展态势，在基础上灵活调度和利用大模型的生成能力（如细化一段需求或生成一段代码）、已有的数字化信息和知识积累（如代码依赖关系、通用组件、软件设计决策等）、各种工具能力（如运行代码静态检查或自动化测试、查询相关的缺陷报告信息以及提交新的缺陷报告等）以及开发人员的主观判断（如作出需求和设计决策、审核大模型产生的结果等）。这一过程的一个突出特点是智能交互引擎主导，将开发人员的经验判断与各种工具的能力以及大模型的智能有机结合，并实现高度顺畅的智能化和自动化开发过程。此外，智能交互引擎还需要实现开发人员与大模型之间的人机交互过程的会话管理，支持以“多线程”的方式与大模型开展交互式探索同时支持这些探索线索的按需拆分（fork）和归并（join）。在此过程中，智能交互引擎需要做好会话状态和上下文的管理和切换。
 
-
-### 17.2.4 结束语 Ending
+### 17.2.4 结束语
 
 拥抱大模型对于软件企业提质增效而言肯定是一个正确甚至必要的方向。但是，如何实现系统和全面的软件智能化开发还需要冷静思考，同时还有很多基础性的工作需要去做。对于企业而言，扎实做好软件开发的数字化和知识化积累以及需求、设计、验证等软件工程基本能力建设仍然是十分重要的，而且也是实现更高水平的智能化开发的基本条件。对于学术研究而言，面向系统和全面的软件智能化开发还是有很多工作可以做的，这也要求我们在理解大模型能力的基础上对于软件系统的复杂性以及软件需求和设计有更深的理解。

基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.3 软件行业的混合办公模式.md

@@ -0,0 +1,223 @@
+
+## 17.3 软件行业的混合办公模式
+
+本小节摘录了来自微软亚洲研究院 DKI 组的一份研究报告，它调查了新冠疫情对软件行业人员的影响，尤其是新型的混合办公模式的体验情况，有助于帮助软件行业的企业管理者进行更合理的决策。
+
+标题：新冠肺炎疫情恢复期间重返办公室—来自中国的早期指标
+原文标题：Returning to the Office During the COVID-19 Pandemic Recovery: Early Indicators from China
+原文链接：https://dl.acm.org/doi/10.1145/3411763.3451685
+原文作者：
+```txt
+· Yun Wang, Microsoft Research Asia, wangyun@microsoft.com
+· Ying Liu, Microsoft STC Asia, liyin@microsoft.com
+· Weiwei Cui, Microsoft Research Asia, weiweicu@microsoft.com
+· John Tang, Microsoft Research, johntang@microsoft.com
+· Haidong Zhang, Microsoft Research Asia, haizhang@microsoft.com
+· Doug Walston, Microsoft STC Asia, doug.walston@microsoft.com
+· Dongmei Zhang, Microsoft Research Asia, dongmeiz@microsoft.com
+```
+
+团队介绍：
+
+数据、知识与智能组（DKI，Data+Knowledge+Intelligence Group）主要从事面向大众的数据智能研究，致力于发掘数据的价值，赋能广大个人和团队用户，帮助他们从数据中获取洞察、提炼和分享知识、并将所得转化为决策和行动。
+
+对于不同领域、不同形式的数据，有三个共同的研究主题——理解、生成和交互。数据理解旨在实现对各类数据的语义理解；数据生成的目标是根据用户的需求自动生成内容；与数据的交互旨在创造自然、高效、富有吸引力的用户体验。
+
+研究方向：数据分析、知识计算、信息可视化与人机交互、软件分析。
+
+### 摘要
+
+新冠肺炎疫情迫使许多人在2020年初突然转向远程工作。但随着各国从疫情中复苏，正如中国从 2020 年春天开始的那样，公司经历了重新开放办公室的过程。人们以混合模式（Hybrid mode）工作，在这种模式下，他们可以决定如何分配在家和办公室工作的时间。在这项研究中，我们探讨了影响员工决策的关键因素是什么。我们对一家全球科技公司在中国的员工进行了调查和采访。这些数据展示了人们在家和办公室之间的工作时间安排，他们在家工作的经历，以及他们喜欢的工作模式。通过访谈，我们确定了人们在混合工作阶段决定在哪里工作的不同策略和原因。
+
+概念：以人为中心的计算—协作和社交计算的实证研究。
+
+关键字：远程工作、在家工作、远程工作、混合工作、新冠肺炎。
+ 
+### 17.3.1 引言
+
+新冠肺炎疫情迫使许多知识工作者在 2020 年初突然转向全球范围的远程工作。对疫情的应对方法使人们在远程工作方面有了大量自然发生的经验，因此这为研究人员提供了一个机会，可以在不同于传统情况的远程工作的背景下研究远程工作主题。
+
+由于疫情形势和应对措施的不同，各国目前从疫情中恢复的进展情况差异很大。一些国家领先于其他国家，冠状病毒的传播已基本得到控制，社会和经济正在从新冠肺炎疫情中恢复。在中国，疫情恢复过程始于 2020 年春季，当时公司经历了重新开放办公室的过程，员工从强制在家工作过渡到在家和办公室工作的混合模式。员工被允许返回办公室，同时仍保持必要时在家工作的灵活性。在混合模式下，员工可以根据各种因素决定如何在家和办公室之间分配工作时间。
+
+尽管最近发表了许多研究以检验新冠肺炎疫情背景下的远程工作经验$^{[5–7,9,25,27,30]}$，但缺乏针对疫情恢复期间混合工作阶段的研究。在这项研究中，我们旨在填补这一空白，以了解员工在混合工作模式下的实践和经验，并探讨影响他们在家和办公室之间工作时间安排的关键因素是什么。具体而言，我们对一家全球科技公司在中国三个城市的知识工作者进行了一项在线调查（N=475）和半结构化访谈（N=12）。在我们进行调查和采访时，他们已经在混合模式下工作了三个多月，因此随着时间的推移，他们的实践和经验基本上稳定了下来。从我们的研究中，我们发现，与完全在家工作相比，参与者在混合工作模式下总体上感知到更高的生产力和更高的满意度。
+
+由于全球一些地区的许多工作场所仍处于关闭状态，我们的研究结果有助于为决策者和组织提供信息，帮助他们规划和准备新冠肺炎疫情恢复期间的混合工作模式阶段。此外，这种前所未有的混合工作模式可能会影响人们对远程工作的态度和策略，这可能表明不同工作模式的优缺点，并为未来的工作规范形成最佳实践。因此，我们的研究可以补充其他研究，并有助于在这种新的实践中全面理解对于远程工作研究。
+
+### 17.3.2 相关工作
+
+远程工作，也称为远程工作、远程办公或在家工作（WFH，Working From Home），为员工提供了灵活的工作安排，他们不需要在中心办公工作场所工作。远程工作已经越来越多地被许多公司所采用。根据盖洛普的一项调查，超过 43%的员工报告称，2017 年每周至少有一天远程工作$^{[17]}$。然而，在现实中，远程工作并不总是被认为是有益的。例如，为了更好的沟通和协作，雅虎禁止员工在家工作$^{[21]}$。远程工作是未来工作的一个重要方面，但其长期影响仍不确定。
+
+先前的研究从各个方面调查了远程工作的好处和缺点$^{[1-3,11,13,20,24]}$。总的来说，许多研究表明，远程工作可以提高生产力并带来更高的工作满意度$^{[4,8,10,18]}$，因为远程工作为员工提供了更灵活的工作时间和更好的工作与生活平衡。另一方面，远程工作可能会对生产力产生负面影响。例如，在家工作可能会降低软件开发中开发人员沟通的效率$^{[29]}$。研究人员还发现了在远程工作期间影响人们幸福感的具体挑战，如模糊工作与生活的界限$^{[2]}$和与同事的社会隔离$^{[15]}$，并且可能因不同类型的工作而有所不同$^{[14,26,28]}$。创造性工作、新的工作流程和需要广泛协作的任务可能比容易编码的工作更难通过远程工作实现。
+
+以前的研究大多是关于非正常情况下的远程工作体验，在这种情况下，远程工作通常只涉及一小部分劳动力和有限的工作角色。对冠状病毒的初步反应要求大多数知识工作者在家工作，并实施了各种健康和社会限制。这些疫情可能改变了在家工作的动态，这表明有必要研究它与传统远程工作的区别。
+
+新冠肺炎疫情应对为研究人员提供了一个独特的时间窗口，以检查大规模远程工作的基本全球实验。研究人员迅速做出反应，及时提出了关于疫情期间远程工作经历的重要发现。例如：
+
+- 几项研究$^{[5,12,25]}$关注的是疫情期间在家工作的软件开发人员的生产力。
+- Yang 等人估计了新冠肺炎期间在家工作对团队协作的影响$^{[30]}$。
+- Nolan 等人探讨了远程工作对幸福感方面的影响$^{[23]}$。
+
+这些研究主要考察了新冠肺炎疫情封锁期间完全在家工作的经历。
+ 
+我们的研究侧重于新冠肺炎疫情恢复混合工作阶段的经验。我们探讨了在疫情恢复期间，员工如何以混合工作模式在家和办公室之间分配工作时间，以及哪些潜在因素影响了他们的决策。有的研究讨论了人们在正常时间远程工作的原因$^{[3,16,19]}$。无论如何，我们的研究说明了疫情期间的差异，即人们首先在疫情应对期间无法选择来办公室，然后经历混合工作阶段，在办公室重新开放后，他们必须决定是否返回办公室。
+
+### 17.3.3 研究方法
+
+在本研究中，我们旨在了解中国人在新冠肺炎疫情恢复的混合工作阶段的经验和做法。具体来说，当人们在混合模式下工作时，我们对三个方面感兴趣：
+
+1）他们如何安排在家和办公室之间的工作时间？
+2）在家工作对他们的工作和幸福感有何影响？
+3）人们在多大程度上更喜欢混合工作模式？
+
+我们对一家全球高科技公司在中国的员工进行了在线调查和后续采访。
+
+#### 1. 背景
+
+2020 年 1 月 23 日凌晨 2 点，武汉发布了封锁通知以防止疫情蔓延。公司很快关闭了中国大陆的办公设施，最初关闭到 2 月 9 日，但后来根据情况的严重性两次延长到 2 月 17 日。2 月 17 日，当情况急剧缓解时，中国的公司逐渐开始欢迎员工回到办公室。
+我们调查的公司是一家跨国科技公司，在中国的好几个城市都有办公室。根据政府的政策和指导方针，该公司于 2 月 17 日谨慎地开放，允许员工重新进入办公室工作场所，尽管仍鼓励人们在家工作以将风险降至最低。从 3 月 13 日起，员工可以在家或办公室以混合工作模式工作。到我们进行调查时，他们已经在混合模式下工作了三个多月。因此，他们可以分享他们的混合工作模式。
+
+#### 2. 调查
+
+我们的调查是使用 Microsoft Forms 实施和分发的。这项调查是完全匿名和自愿的。由于英语是公司的官方语言，它总共包含 38 个英语问题。在调查之前，该研究进行了合规性审查，并获得了该机构道德审查委员会对研究程序的批准。平均来说，完成大约需要 18 分钟。为了鼓励参与，参与者可以在单独的表格中输入自己的名字，参加抽奖，赢取 20 份礼物。除了收集人口信息的问题（例如，性别、工作角色、工作纪律、地点）外，我们的调查还包括以下问题：
+
+- 在家工作的体验，包括在家工作时的整体工作效率和工作满意度，以及从个人工作、团队协作和人类福祉的各个方面（例如，无通勤、工作与生活平衡、社会隔离）来看远程工作的好坏。
+- 家庭和办公室之间的工作时间安排，包括他们每周在办公室工作多少天，以及返回办公室的具体原因和考虑因素。
+- 与新冠肺炎期间完全在家工作和新冠肺炎之前完全在办公室工作相比，对混合工作模式的偏好。
+
+该调查于 2020 年 6 月通过电子邮件发送给该公司 3170 名员工。我们在两周内共收到475 份回复，回复率为 15%。在所有受访者中：
+- 66.3%的人表示自己是男性，22.3%的人表示是女性，11.4%的人没有表示自己的性别。
+- 38.1%的受访者表示他们和孩子住在一起。受访者的工作角色包括软件工程师（70.1%）、项目经理/设计师（14.3%）、研究员（10.1%）、业务运营（2.1%）、销售/市场营销（1.5%）和数据科学家（1.1%）。19%的受访者是经理。
+- 关于他们以前在家工作的经历，55.2%的受访者从未在家工作过，33.7%的人偶尔在家工作，11.1%的人经常在家工作。
+- 大多数受访者位于三个城市：北京（57.9%）、苏州（20.4%）和上海（20.4%的）。北京和上海分别是华北和华东的两个主要大都市；而苏州在东部是一个中等规模的城市。
+
+#### 3. 专访
+
+我们在 2020 年 7 月和 8 月对该公司的 12 名员工进行了半结构化采访。采访进一步深入探讨了他们的决策和策略的根本原因。有意从我们的调查对象中邀请参与者，涵盖不同的性别、学科、角色和地点（表 17.3.1）。
+
+表 17.3.1 访谈参与者
+
+|采访人序号|性别|训练|角色|地方|
+|-|-|-|-|-|
+|P1|男|研究员|经理|北京|
+|P2|女|项目经理|经理|北京|
+|P3|男|工程师|经理|北京|
+|P4|女|研究员|普通职员|北京|
+|P5|男|工程师|普通职员|上海|
+|P6|女|销售/营销|普通职员|上海|
+|P7|女|设计师|普通职员|北京|
+|P8|男|工程师|普通职员|苏州|
+|P9|男|项目经理|普通职员|苏州|
+|P10|男|工程师|经理|北京|
+|P11|女|业务经理|经理|苏州|
+|P12|女|工程师|普通职员|北京|
+
+在 8 月份的数据收集过程中，他们都在混合模式下工作。每个采访约一个小时，通过远程电话会议用普通话进行。我们为每个环节录制了音频。访谈调查了参与者是如何工作的，他们在计划工作时采取的策略，他们对时间安排的考虑，以及他们所经历的好处和挑战。还询问了关于他们的工作职责和团队合作的更具体的问题，以了解他们选择背后的原因。我们采用描述性分析方法对访谈数据进行了分析$^{[22]}$。对于每个参与者，我们仔细观察他们在混合模式下工作时分享的有趣故事。这些有趣的故事有助于我们理解他们的感受、想法和行为背后的动机。
+
+### 17.3.4 结果
+
+#### 1. 家庭和办公室之间的工作时间安排
+
+在办公室软开放后的混合工作模式下，员工可以灵活选择在家工作或在办公室工作。通过调查和采访，我们询问了参与者他们是如何划分的，他们在家和办公室之间的工作时间，以及他们背后的考虑因素。
+
+我们的调查显示，办公室和家之间的时间安排是多样化的。
+
+- 10.7%的受访者表示他们完全在家工作，20.2%的受访者完全在办公室工作，但近70%的受访者选择将在家工作和在办公室工作的好处结合起来。
+- 在那些回到办公室的人中，大约一半的受访者（51.3%）遵循常规日程安排，另一半（48.7%）按需前往办公室；
+- 16%的受访者表示平均每周在办公室一天，相应的百分比为两天（20%）、三天（22%）、四天（18%）和五天（24%）。在办公室工作的平均天数也各不相同。
+
+在家工作的好处和挑战在很大程度上影响了以混合模式返回办公室的考虑。我们的调查确定了吸引受访者在办公室工作的几个因素：
+
+- 包括更好的工作场所设置（63%）、亲自会面（43%）、与同事的社交活动（43%）以及在办公室完成特定任务（42%）。
+- 另一方面，提到了在家工作的几个考虑因素，包括节省通勤时间（59%）、必要的家庭护理（42%）、更多的专注时间（39%）、降低健康风险（33%）和天气（27%）。
+
+考虑因素可能因地点不同而有所不同。例如，我们发现苏州的受访者比其他城市的人更多地考虑天气因素。从与苏州参与者的相互看法来看，这可能是因为在调查期间，苏州正处于梅雨季节，大量降雨使通勤更加困难。
+
+同事的日程安排是人们可能会考虑的一个因素。
+- 在办公室工作的受访者中，超过 45%的人表示，他们与其他同事就何时上班进行了协调。我们采访中的一位参与者（P4）明确提到：“这样，我就有机会与同事面对面进行深入讨论。”尽管他们咨询了经理，但当参与者决定在家或办公室工作时，他们通常不会感受到来自他人的压力。
+- 70.1%的受访者认为他们如何安排时间“完全或主要是我的决定”。
+- 只有 6.1%的人表示是他们的经理做出了决定。
+- 42.8%的受访者认为没有义务透露在家或办公室工作的原因。
+
+我们所有的受访者都提到，他们在办公室和家中安排工作时间时很灵活，有自主权，并认为他们的经理和同事支持他们的决定。
+
+#### 2. 在家工作的经历
+
+在家工作时，大多数参与者认为他们团队的整体生产力与新冠肺炎之前相比保持不变，甚至有所提高。首先，与团队合作经验有关，据报道，各种沟通和协作工具的使用量显著增加。具体而言，受访者报告了在线协作平台（85.3%）、电话（55.6%）、电子邮件（44.9%）和微信等社交通信工具（45.8%）的使用情况。许多受访者报告了显著增加的或创建的群组（36.8%）和一对一（38.6%）会议。一位参与者（P8）表示，“更频繁地与团队定期同步会议可以让团队成员更喜欢在办公室工作。”
+
+会议体验在效率和灵活性方面总体上令人满意。然而，会议的有效性略有下降，这可能是由于合作/沟通工具的局限性和缺乏面对面的参与。一位营销团队受访者（P6）告诉我们，在完全在家工作的几个月里，她与同事们安排了更多的一对一会议，而在办公室工作时不需要这样做。据她说，“如果我们不能见面或随意聊天，许多信息就会丢失，因此我可能会在同事中失去自我意识，我必须利用额外的1对1会议来弥补这一点。”
+
+在家工作时，人们也会错过与队友和同事的社交和身体互动。对于“你最怀念在办公室工作的什么？请检查所有适用的内容。”
+- 这一问题，受访者提到了缺少工作场所设施（55%）、氛围（53%）、午餐时的社交互动（43%）和与队友的身体交流（43%）。
+- 在我们的后续采访中，几位参与者表达了他们对这个问题的担忧，并试图在商务会议或在线小组活动中进行更多的闲聊。一位参与者（P11）说：“现在我们正在将游戏转移到网上，我们的队友真的很享受。”
+
+在我们的调查中，我们使用了两个问题“与新冠肺炎之前相比，您的生产力发生了什么变化？”和“请对您在新冠肺炎期间在家工作的总体满意度进行评分？”来调查参与者在家工作时的总体生产力和满意度。受访者报告了更高的个人生产力（6%的生产力显著提高，31%的生产力提高，43%的生产力大致相同，18%的生产力降低，1%的生产力显著降低）。
+
+然而，随着时间的推移，情况也发生了变化。人们经历了一段学习曲线，以掌握时间管理技能，从而保持一定的生产力水平。
+- 一位受访者（P3）提到，起初他们不确定如何使团队会议足够有效，并评论道：“我的队友经常认为在线会议太正式，所以他们更不愿意谈论琐碎的话题。”但经过一段时间的尝试和错误，他们学会了如何更好地利用远程团队会议。
+- 我们调查的参与者报告的数字甚至更高。新冠肺炎期间在家工作的满意度（22%非常满意，45%稍微满意，15%既不满意也不满意，14%稍微不满意，5%非常不满意）。他们解释说，在家工作可以降低健康风险，同时仍然保持令人满意的生产力水平。一位参与者（P7）告诉我们，“我觉得WFH对我和我的家人来说都很有价值。我和家人可以在一起，我自己也可以继续工作。”
+
+为了了解在家工作的体验因素如何与感知的生产力和满意度相关，我们计算了与在家工作体验有关的特定问题与生产力和满意度感知之间的皮尔逊相关性。表 17.3.2 和表 17.3.3 显示了在家工作时，体验问题与感知生产力和满意度之间的相关性高于 0.3 或低于 -0.3。一些有趣的相关性：对工作的更好控制感、更高效的会议和更多的时间完成工作与更好的整体生产力有关；在家工作时，更好的工作与生活平衡和更少的花钱与更高的满意度有关。
+
+表 17.3.2 与工作效率的相关度绝对值大于 0.3 的WFH体验问题
+
+|WFH 体验问题|相关度|p 值|
+|-|-|-|
+|有更好的工作环境|0.473998|p<0.001|
+|很少分心或被打扰|0.473791|p<0.001
+|对工作有更多的控制权|0.386096|p<0.001
+|有更高效的会议|0.333623|p<0.001
+|有更多的时间来完成工作|0.321148|p<0.001
+|对与他人缺乏情感联系感到难过|-0.31091|p<0.001
+|对缺乏与同事的社交互动感到难过|-0.32218|p<0.001
+|对同事的工作不太了解，感觉很糟糕|-0.32633|p<0.001
+|很糟糕，因为缺少说明复杂问题的设施（如白板）|-0.34024|p<0.001
+|很难与同事沟通和协调|-0.35327|p<0.001
+|很糟糕，因为缺乏规则和流程|-0.35664|p<0.01
+
+表 17.3.3 与满意度的相关度绝对值大于 0.3 的WFH体验问题
+
+|WFH 体验问题|相关度|p 值|
+|-|-|-|
+|有更好的工作环境|0.363075|p<0.001|
+|有更好的工作与生活平衡|0.335823|p<0.001|
+|在通勤、食物等方面花更少的钱很好|0.317482|p<0.001|
+|对与他人缺乏情感联系感到难过|-0.31091|p<0.001|
+|很糟糕，因为缺乏规则和流程|-0.31931|p<0.001|
+|对同事的工作不太了解，感觉很糟糕|-0.33301|p<0.001|
+
+#### 3. 混合工作模式是首选项
+
+在调查中，我们要求参与者将混合模式下的生产率与新冠肺炎之前的在职生产率进行比较：
+- 混合模式被认为“生产率更高”（10.3%）和“生产率更大”（38.2%）。
+- 只有少数人投了反对票（5.5%“生产率稍低”，0.6%“生产率更低”）。
+
+关于他们喜欢的工作模式：
+- 69%的受访者选择了混合模式；
+- 19%的受访者更喜欢完全在家工作；
+- 11%的受访者更愿意完全在办公室工作。
+
+在采访中，我们还询问了参与者对未来工作的展望。
+
+- 大多数参与者倾向于将混合工作模式作为新冠肺炎疫情后的一种工作选择，因为通过混合模式，知识工作者通常可以结合在家和办公室工作的优点，以最大限度地提高生产力和灵活性。正如我们的一位受访者（P12）告诉我们的那样，“在家工作时，我感觉更有效率。在家工作对我来说唯一的缺点是缺乏社交机会。这就是为什么我喜欢混合模式。”
+
+- 一位项目经理（P2）喜欢办公室的工作氛围不喜欢远程工作。但她仍然支持混合动力模式。她评论道：“我不认为长期在家工作会奏效，但我相信混合工作可能是未来的最佳解决方案。它可以为我们提供很大的灵活性，以利用远程工作和办公室工作的好处。”
+
+- 然而，混合工作模式面临着各种挑战。例如，一位参与者（P1）在采访中提到，他很难同步家用机器和办公机器。他指出，“必须进行特殊设置，以使未来家用电脑和办公电脑之间的转换更加顺利，但每次移动到不同的地方都需要在那里重新配置和同步电脑。”
+
+### 17.3.5 讨论和限制
+
+应该注意的是，这一混合工作阶段的背景是人们在长期封锁后首次体验到的。人们在混合模式下的行为、感知和偏好可能是由刚刚摆脱封锁的反弹效应决定的。人们在家工作的经历也可能与其他国家的远程工作政策和疫情进展有关。例如，一位受访者（P7）表示，由于美国（公司总部所在地）有大量同事在家工作，因此美国在晚上可以举行更多会议。
+
+调查参与者和受访者普遍对在家工作感到满意。然而，我们也发现，在家里缺乏适当的工作场所设置是影响体验的一个重要因素。对于那些有私人安静的工作场所和不间断的时间，他们更喜欢在家工作。如果人们很容易被打扰，那么在家工作时的高生产力可能更难实现。
+
+通信技术是另一个可能有助于有效远程工作的重要因素，尤其是对于需要大量协作的信息工作者来说。由于人们无法在会议室面对面交流，也无法利用白板讨论问题，因此在家工作的效率降低了。因此，人们选择进入办公室来弥补这些不利因素。为了支持更好的远程工作，应该增强通信工具，以弥补由于无法见面而导致的通信效率低下，尤其是在提供共享绘图工具的情况下。
+
+重要的是要记住我们重新研究人们对混合工作模式的行为和态度的不同寻常的背景。在疫情的特殊情况下，有许多因素也影响了人们的判断和决策。例如，在疫情初期，一些公共交通受到限制，这可能会直接影响人们通勤到办公室的决定。此外，公共卫生官员鼓励人们保持社交距离，减少旅行，这可能会让人们在家工作时感到更安全。此外，在混合工作模式下，幼儿园和学校没有开放，因此家长在家工作时可能需要积极管理孩子。
+
+这项研究的重点是中国一家信息技术公司的工作经验，我们曾接触过该公司调查并采访其员工。必须承认数据仅来自一家公司的局限性。这家公司专注于信息技术产品及其技术基础设施，使得大部分工作都可以在家远程进行。作为一家总部设在美国的全球性公司，中国的工作政策涉及与全球企业政策的一些协调，这可能与总部设在中国的公司不同。
+
+### 17.3.6 结束语
+
+我们列出了对中国一家全球科技公司员工进行的在线调查和访谈的结果，以了解他们在新冠肺炎疫情恢复期间的混合工作模式经历。这项研究展示了中国知识型员工如何在家和办公室之间安排工作时间，还揭示了可能影响人们在家工作和返回办公室的体验的各种因素，以及他们为时间安排所采取的策略。这些数据可以将中国的做法与世界其他地区收集的数据进行比较。此外，这些结果有助于改善其他地区的混合重返工作岗位体验，特别是关注所列因素如何影响人们在工作场所重新开放时选择重返工作岗位。
+
+*由于篇幅有限，参考文章链接没有列出，有兴趣的读者可以阅读原文。*

基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.4 深度学习平台质量问题实证研究.md

@@ -0,0 +1,473 @@
+
+## 17.4 深度学习平台故障的研究
+
+本小节摘录了来自微软亚洲研究院系统组的一份研究报告，调研了微软内部使用的深度学习平台的质量问题，给出了分析和解决方案。
+
+标题：深度学习平台质量问题的实证研究
+原文标题：An Empirical Study on Quality Issues of Deep Learning Platform
+原文链接：https://www.microsoft.com/en-us/research/publication/an-empirical-study-on-quality-issues-of-deep-learning-platform/
+原文作者：
+```txt
+· Yanjie Gao, Microsoft Research Beijing China, yanjga@microsoft.com
+· Xiaoxiang Shi, Microsoft Research Beijing China, v-xiaoxshi@microsoft.com
+· Haoxiang Lin, Microsoft Research Beijing China, haoxlin@microsoft.com
+· Hongyu Zhang, Chongqing University Chongqing China, hyzhang@cqu.edu.cn
+· Hao Wu, Microsoft Beijing China, wuh@microsoft.com
+· Rui Li, Microsoft Beijing China, ruli1@microsoft.com
+· Mao Yang, Microsoft Research Beijing China, maoyang@microsoft.com
+```
+
+主要作者简介：
+
+高彦杰，微软亚洲研究院高级研发工程师。研究兴趣为深度学习平台工具和大数据系统的鲁棒性，效率与可调试性，积极参与人工智能系统教育。其中多项工作发表在著名系统与软件工程会议ICSE，ESEC/FSE，SoCC，并出版多部技术图书。
+
+### 摘要
+
+近年来，深度学习（DL）在许多应⽤领域中得到越来越多的采⽤。为了帮助深度学习开发者更好地训练和测试他们的模型，很多云计算服务已经建⽴了专⽤的多租户平台，配备了 GPU 等⼤量计算设备。这些平台的服务质量对系统效率和⽤户体验起着⾄关重要的作⽤。然⽽，确实存在各种类型的质量问题，不仅会严重浪费计算资源，还会严重降低开发效率。在本⽂中，我们对微软的 Platform-X 质量问题进⾏了全⾯的实证研究。 
+
+Platform-X 是⼀个内部使用的深度学习平台，为数千名开发⼈员和研究⼈员提供服务。我们⼿动检查了 360 个真实的问题，并调查了它们的常⻅故障、根本原因和缓解措施。主要发现如下：
+- 28.33%的质量问题是由硬件（GPU、⽹络和计算节点）故障引起的；
+- 28.33%的原因是系统端故障（如系统缺陷、服务中断）；
+- ⽤户端故障（如⽤户BUG、违反政策等）占所有常⻅原因的五分之⼆以上（43.34%）；
+- 超过五分之三的质量问题可以通过简单地重新提交作业（34.72%）和改进⽤户代码（24.72%）来缓解。
+ 
+我们的研究结果为从开发和维护两个⽅⾯提升深度学习平台的服务质量提供了有价值的指导，并进⼀步激发了可能的研究⽅向和⼯具⽀持。
+
+索引词：深度学习，深度学习平台，质量问题，实证研究
+
+### 17.4.1 引言
+
+近年来，深度学习（DL）在许多应⽤领域得到越来越多的采⽤，例如⾃然语⾔处理$^{[1,2]}$、强化学习游戏 $^{[3]}$、计算机编程 $^{[4]}$ 和卫星图像$^{[5]}$。IT 企业已经构建了专⽤的多租户平台（例如，Microsoft Azure Machine Learning $^{[6]}$、Amazon SageMaker $^{[7]}$ 和Google Cloud AI $^{[8]}$），为开发⼈员提供便捷的深度学习训练和推理服务。这些 DL平台配备了⼤量计算设备（如 CPU、GPU 或 TPU），并在内部与⾼速⽹络互连（如通过 InfiniBand $^{[9]}$），⽀持各种 DL 框架和PyTorch $^{[10]}$、TensorFlow $^{[11]}$ 和 Hugging Face $^{[12]}$等库。
+
+在 Microsoft 内部，数千名开发⼈员和研究⼈员每天使⽤内部⽣产 DL 平台 Platform-X 来训练和测试他们的模型，以完成⼴告和机器翻译等各种任务。 Platform-X 是⽤⼴泛使⽤的开源软件（例如 Kubernetes $^{[13]}$）和商⽤计算硬件（例如 GPU）搭建的，并且在架构上与上述公开的 DL 平台相似。对于Platform X，其核⼼任务之⼀是在遇到意外的硬件和软件故障时，根据它的服务⽔平协议（SLA）保证每个⽤户的服务质量。尽管采取了很多质量保证措施，但实际上，许多 DL 作业仍然存在严重的质量问题，⽆法提交、运⾏速度很慢、挂起，甚⾄意外失败。这些质量问题不仅会影响⽤户体验，还会影响企业⽣产⼒。⽤户在遇到质量问题时，通过问题管理系统反馈，希望服务站点的可靠性⼯程师（SRE）尽快诊断并解决，这也给平台⽀持团队带来了沉重的运维负担。因此，了解 Platform-X 中提出的质量问题，包括它们的故障、根本原因和缓解措施，对于帮助平台⽀持团队最⼤限度地提⾼效率和帮助平台⼯程团队改进系统设计和实施变得尤为重要。
+
+- 以前有很多关于传统软件系统质量问题的⼯作$^{[14...22]}$。例如，Zhou 等⼈$^{[19]}$ 研究了来⾃微软内部⼤数据分析平台的 210 个随机选择的质量问题。
+
+- 最近，我们看到了⼀些与深度学习相关的实证研究 $^{[23...31]}$，重点关注 DL 框架、编译器、程序和作业的失败和错误。例如，Zhang 等⼈$^{[27]}$ 研究了在三周内从 Microsoft 收集的 4,960 个内部 DL 作业失败。然⽽，仍然缺乏关于 DL 平台质量问题特征的专⻔研究。
+
+在本⽂中，我们对深度学习平台的质量问题进⾏了全⾯的实证研究。我们从 Platform-X 的问题管理系统中随机抽取了 2021 年 11 ⽉⾄ 2022 年 2 ⽉开发⼈员和研究⼈员报告的 360 个质量问题。对于每个质量问题，我们收集了其相关信息，例如问题描述，讨论、根本原因、缓解措
+施、最终修复解决⽅案等。我们还收集了有关受影响⼯作的相关信息。该研究的⽬的是提供对 DL 平台质量问题的系统和概括的理解。 
+
+由于与公开的平台的软硬件架构相似，因此，这项研究的结果并不特定于微软，也可以应⽤于其他公司的深度学习平台。具体来说，我们的研究旨在解决以下三个研究问题（RQ，Research Question）：
+
+**RQ1：深度学习平台质量问题的常⻅故障是什么？
+RQ2：这些质量问题的常⻅根本原因是什么？
+RQ3：平台⽀持团队采取的常⻅缓解措施有哪些？**
+
+通过对这三个问题的回答，本⽂做出以下贡献：
+
+- 对⽣产深度学习平台的质量问题进⾏了⾸次全⾯研究，检查了 360 个质量问题并⼿动分析它们的故障、根本原因和缓解措施。
+- 指出了我们的发现的意义，并提出了对深度学习平台的开发和运营可能的改进。
+
+### 17.4.2 背景
+
+Platform‑X 是微软的内部生产 DL 平台，服务于数百名开发人员和研究人员。用户每天都会在 Platform‑X 上提交和执行数以千计的 DL 作业，用于他们的日常工作，例如机器翻译、游戏、对象检测和广告。
+
+Microsoft 使用通用的硬件和广泛使用的开源软件构建 Platform‑X。例如，Platform‑X 部署在多个物理 GPU 集群上，并使用 Kubernetes$^{[13]}$进行任务规划、容器编排和异构硬件管理。 Platform‑X 还采用了标准的 DL 编程范式：它准备了由 Python、NVIDIA CUDA/cuDNN/cuBLAS 运行时、 PyTorch $^{[10]}$ 和 TensorFlow $^{[11]}$ 等 DL 框架等组成的各种标准 DL Docker $^{[34]}$ 镜像，以及如 Fairseq $^{[35]}$ 这样的流行库来建立一个封闭的作业执行环境。
+
+<img src='img/platform-x.png'>
+
+图 17.4.1 Platform-X 概览 
+
+图 17.4.1 简要说明了 Platform‑X 的工作流程。 Platform‑X 的系统架构和作业管理与Microsoft Azure Machine Learning $^{[6]}$、Amazon SageMaker$^{[7]}$	和 Google Cloud AI $^{[8]}$ 等公共 DL 平台非常相似。用户首先操作门户网站或用于将所有材料（包括输入数据、Python 程序、shell 脚本和可能的模型检查点）上传到分布式存储（例如，Azure Blobs）的命令行工具。接下来，用户为他们的作业指定资源配额（例如，GPU 型号和数量）、Docker镜像、启动 shell 脚本、主要 Python文件、输入/输出路径和其他配置。
+
+用户还可以指定预装了所有依赖库的自定义 Docker 镜像。一旦提交的作业被选择运行，Platform‑X 的调度程序使用群调度 $^{[36]}$ 算法立即分配所有请求的资源，并在一个或多个 GPU 计算节点上实例化容器。Platform‑X 中的计算节点是配备了GPU、CPU、主内存、磁盘和网络接口卡的物理服务器或虚拟机。之后，此类作业的 DL 训练代码会迭代更新可学习参数（即权重和偏差），直到模型学习性能（例如预测准确性）达到我们的预期。最后，当模型训练完成后，作业将最终的模型文件和评估结果保存到分布式存储中。
+
+### 17.4.3 Platform‑X中的质量问题处理
+
+Platform‑X 采用标准且定义明确的流程来处理质量问题。
+
+- 首先，用户从门户网站登录到 Platform‑X 的问题管理系统并创建问题项。他们遵循提供的模板之一来详细描述问题，例如，包括标题、问题描述、建议的严重级别、作业 URL、失败消息和自定义 Docker 映像标签。鼓励以附件形式提交更多补充信息，例如运行时日志和性能指标。
+
+- 然后，问题管理系统将新的质量问题交付给适当的站点可靠性工程师（Site Reliability Engineer, SRE），以根据问题类型和历史统计数据进行调查。SRE 调用一个集成工具来自动发现以前重复的、相似的或相关的质量问题。如果没有找到，SRE 将遵循正式的故障排除指南在自上而下的过程中逐步调查问题。SRE 通过审查错误消息或异常性能指标，从受影响作业流程的故障或异常站点开始。在分析了程序和运行时日志之后，她试图推断出问题的关键路径。在故障排除决策规则的指导下，SRE 深入研究关键路径中的瓶颈或失败阶段，以确定根本原因。
+
+- Platform‑X 为上述问题诊断记录了各种遥测数据。这些数据包含作业元数据、性能指标和运行时日志，其中大部分列在表 17.4.1 中。作业元数据包括时间统计信息（例如，作业/进程开始和结束时间）、分配的资源（例如，GPU 规格和数量）和依赖软件。性能指标包括各种资源的使用（例如，GPU/CPU 的平均利用率）和节点状态（即，健康或故障）。运行时日志包括由用户代码、运行时、系统组件和硬件驱动程序打印的常规和失败消息。
+
+表 17.4.1 质量问题分析所依据的日志数据
+
+|维度|分类|举例|
+|-|-|-|
+|作业信息|Time|作业提交时间，启动和结束时间，排队时间，运行时间|
+||Resource|GPU/CPU 数量，输入输出存储|
+||Software|GPU驱动，操作系统，NVIDIA驱动，Python版本，平台和库的版本|
+|性能指标|Computing|平均和峰值的 GPU/CPU 使用|
+||Memory|全部/可用容量，平均/峰值使用量|
+||Disk|总容量，可用容量，读写字节数|
+||Network|InfiniBand或以太网收发字节数|
+||Node|健康或出错状态|
+|运行日志|User|user-specified logs in the source code, containing execution progress, input data size, epoch number, batch size, accuracy, loss, model type, etc.|
+||System|logs of runtimes, system components, and hardware drivers, such as “NCCL INFO NET/IB: Using $^{[0]}$mlx x:xx”|
+||Failure|exception and error messages, such as “uncorrectable NVLink error detected”|
+
+
+- 接下来，SRE 调整严重级别，并通过服务级别协议（SLA）提出缓解措施，以保持用户的工作继续进行。缓解措施来自针对先前重复/相似/相关质量问题的参考操作、故障排除指南中的说明以及她的领域知识。 SRE 定期通过 Microsoft Teams 或电话与用户联系，讨论细节、寻求澄清并报告进度。与用户的每次交互都会在问题记录中仔细记录下来。
+
+- 最后，如果质量问题是由硬件或平台端故障引起的，SRE 会调查最终修复方案（17.4.6-1 和 17.4.6-2）。有时，问题超出了 Platform‑X 的责任（例如，由完全损坏的计算节点或分布式存储中断引起），因此她将其所有权转移给相应的团队。在关闭质量问题后，SRE 也更新了问题排查指南，方便后续处理类似问题。
+
+### 17.4.4 实证研究方法
+
+#### 1.	研究目标
+
+我们将 Platform‑X 的真正质量问题作为我们的研究对象。它们是开发人员和研究人员在 2021 年 11 月至 2022 年 2 月的四个月期间提交的。存在重复的质量问题，因为多个用户同时受到单个事件的影响（例如，集群不可用）；因此，我们删除了重复数据。最后，我们从整套中随机抽取了 360 个质量问题。
+
+对于每个质量问题，我们收集了所有相关信息以供后续调查，包括例如用户名、组、集群、作业URL、问题标题、描述、附件、问题状态更新的时间戳、严重级别、讨论详细信息、缓解措施操作、根本原因、相关问题和最终修复解决方案。如果作业 URL 存在，我们进一步尝试提取作业元数据（例如，GPU 编号和最终作业状态）、执行日志和各种运行时指标（例如，GPU 利用率和网络发送/接收的字节数）。
+ 
+#### 2. 数据标注
+
+对于 360 个质量问题，我们都仔细检查了其相关信息（特别是问题描述和讨论），并手动标注了故障、根本原因和缓解措施，以回答三个研究问题。为了减少不可避免的主观性，两位作者独立阅读所有与问题相关的信息以进行数据标注。
+
+我们首先提取了上述三个维度的关键句和短语，然后根据已有的相关研究（如Zhou等人$^{[19]}$和Zhang等人$^{[27]}$）将其细化为分类模式和我们的领域知识。当不确定某些细节时，我们直接联系问题提交者和相应的 SRE 寻求帮助。
+
+#### 3.	有效性顾虑
+
+Threats to Validity，直译为有效性威胁，意为该研究的有效性是不是会被质疑，所以笔者以为“有效性顾虑”。
+
+- 内部有效性的顾虑
+
+    尽管有一些参考资料（例如问题描述和用户 SRE 讨论）可以帮助调查故障、根本原因和缓解措施，但由于大量的手动工作和深度学习固有的复杂性，主观性是不可避免的质量问题。为了减少这种威胁，两位作者独立分析并标记了每个质量问题，在有分歧的情况努力达成共识。
+
+    当遇到复杂的问题时，我们直接联系提交者和对应的 SRE 寻求帮助。
+
+- 外部有效性的顾虑
+
+    我们对从 Platform‑X 收集的质量问题进行实证研究。因此，某些发现可能仅限于微软，可能不再适用于其他公司的深度学习平台，尽管 Platform‑X 在系统架构、软件堆栈、深度学习工具链、作业管理和质量问题处理方面与它们相似。为了减少这种威胁，我们尽量不在本文中得出仅适用于 Platform‑X 和 Microsoft 的特定结论。我们将在第 17.4.8-1 中讨论我们发现的一般性。
+
+
+### 17.4.5 常见故障是什么？
+
+在本节中，我们将研究质量问题的常见故障。故障是用户观察到的质量问题的主观证据，可以在问题标题和描述中发现。表 17.4.2 列出了故障分类，共包括七类。
+
+表 17.4.2 故障分类
+
+||分类|数量|比例|
+|-|-|-|-|
+|1|Job Crash 作业崩溃|198|55.00%|
+|2|Job Submission Failure 作业提交失败|51|14.17%|
+|3|Abnormal Job Behavior 异常行为|46|12.78%|
+|4|Job Hang 作业挂起|27|7.50%|
+|5|Cluster Unavailability 簇不可用|21|5.83%|
+|6|Job Slowdown 作业缓慢|11|3.05%|
+|7|Data Loss 数据丢失|6|1.67%|
+||Total|360|100.00%|
+
+由于用户更关心他们的 DL 工作，因此绝大多数故障（Job五类共333/92.50%）都与特定工作有关。最大的类别是工作崩溃（198/55.00%），超过总数的一半。例如，一个32‑GPU的分布式训练作业运行了很长时间，突然打印出一条错误消息，报告 NVIDIA 集体通信库（NCCL）$^{[37]}$ 超时，然后崩溃。其余四个与工作相关的类别，按数量排序，分别是工作提交失败（51/14.17%）、工作行为异常（46/12.78%）、工作挂起（27/7.50%）和工作放缓（11/3.05%）。异常作业行为意味着 DL 作业似乎执行良好，但它表现出一些异常行为。例如，一位用户注意到分配的四个 GPU 中只有一个按预期工作，但其他的自作业开始以来一直处于闲置状态。
+
+两类故障与特定的 DL 作业没有直接关系。一是Cluster Unavailability（21/5.83%），这意味着GPU集群无法再为作业提交和执行提供连续服务（例如，由于中断或集群维护）。例如，一位用户发现一个集群的某些 GPU 在 Platform‑X 的门户网站上不可用，并且他和其他同事向该集群提交的任何作业不断失败。另一个是数据丢失（6/1.67%），表示用户突然莫名其妙地丢失了数据。例如，分布式存储上的一个输入数据文件夹毫无征兆地消失了。另一个例子是用户无法查询其历史 DL 作业的日志数据。
+
+**【发现1】几乎所有的常见故障（92.50%）都与具体的深度学习工作直接相关，其中最大的一类是Job Crash（55.00%），超过总数的一半。
+【含义】失败的 DL 作业会浪费大量的计算资源和时间。因此，用户和平台应该共同努力减少和容忍作业失败，例如改进用户代码和实施更有效的模型检查点技术。**
+
+此外，我们对质量问题的严重程度进行分类。
+
+如第 17.4.3 节所述，用户在向 Platform‑X 支持团队提交质量问题时需要根据业务影响声明严重级别。问题管理系统和 SRE 参考用户提出的严重性来确定问题处理的优先级（例如，确定缓解措施所需的时间）。请注意，SRE 可能会根据以前/类似的质量问题和她的领域知识来调整严重性级别，以反映更准确的情况。Platform X 采用三个严重级别：高、正常和低。表 17.4.3 显示了所有问题的严重程度分布。
+
+表 17.4.3 严重程度分布
+
+|严重程度|数量|比例|
+|-|-|-|
+|High|19|5.28%|
+|Normal|329|91.39%|
+|Low|12|3.33%|
+
+我们观察到绝大多数（329/91.39%）的质量问题属于正常级别。只有19个（5.27%）的质量问题是高级别的，这需要支持团队在立刻处理，及时定期向用户更新进度，并在规定的时间内采取成功的缓解措施。其余 12 个（3.33%）问题处于低级别。
+
+### 17.4.6 常见的根本原因是什么？
+
+在本节中，我们将对 360 个问题的常见根本原因进行分类，我们将它们分为三个主要维度：硬件、平台端和用户端，表 17.4.4 显示了这些维度的总体分布。
+
+表 17.4.4 故障的总体分布
+
+||维度|数量|比例|
+|-|-|-|-|
+|1|Hardware Fault 硬件故障|102|28.33%|
+|2|Platform-side Fault 平台侧故障|102|28.33%|
+|3|User-side Fault 用户侧故障|156|43.34%|
+||Total|360|100%|
+
+#### 1. 硬件故障
+
+Platform‑X 由 NVIDIA GPU 和 InfiniBand 网络等异构商品硬件构建，可能会遇到相对较高的硬件故障概率。表 17.4.4 表明硬件故障是主要的根本原因类型，导致近三分之一（102/28.33%）的质量问题。
+
+硬件故障有 11 分类，我们进一步将它们分为三组：GPU、网络和节点。硬件故障的详细分类和分布如表 17.4.5 所示。
+
+表 17.4.5 硬件故障（Hardware Fault）分类
+
+|分组|分类|数量|比例|
+|-|-|-|-|
+|**GPU**|**Subtotal**|**20**|**5.55%**|
+|1|GPU Memory Fault|9|2.50%|
+|2|GPU Unavailability|5|1.39%|
+|3|NVLink Error|4|1.11%|
+|4|Broken GPU Driver|2|0.55%|
+|**网络**|**Subtotal**|**25**|**6.95%**|
+|1|InfiniBand Port Down|6|1.67%|
+|2|InfiniBand Slowdown|5|1.39%|
+|3|InfiniBand Other Faults|6|1.67%|
+|4|Ethenet Fault|8|2.22%|
+|**节点**|**Subtotal**|**57**|**15.83%**|
+|1|Node Outage|50|13.89%|
+|2|Node Damage|5|1.39%|
+|3|Node Preemption|2|0.55%|
+
+1）GPU
+
+GPU 是深度学习工作的主要计算设备。长时间和繁重的工作量可能导致各种 GPU故障 $^{[38...41]}$。
+
+- 第 1 类是 GPU 内存故障，这意味着 9（2.50%）质量问题是由GPU内存故障引起的。典型案例包括不可纠正的 ECC（纠错码）错误、GPUMMU（内存管理单元）错误、非法内存访问和内存泄漏。例如，具有 56 个 GPU 的长时间运行的分布式训练作业突然抛出 CUDA 运行时错误并失败。在使用 NVIDIA 数据中心 GPU 管理器（DCGM）$^{[42]}$ 进行进一步诊断后，SRE 最终确定此类作业失败的根本原因是一个 GPU 引发了 ECC 错误。
+- 有时，DL 作业无法找到或注册分配的 GPU，因为出现 GPU 不可用故障。此类别有 5 个（1.39%）质量问题。
+- 第 3 类是 NVLink 错误，包含 4 个（1.11%）质量问题。NVIDIA NVLink 是一种直接的 GPU 到 GPU 互连，可在计算节点内扩展多 GPU 输入/输出$^{[43]}$，用于分布式 DL 训练。下面显示了示例 NVLink 错误的失败日志。
+
+```
+1 ...
+2 terminate called after throwing an instance of 'c10::Error'
+3 what(): CUDA error: uncorrectable NVLink error detected during the execution
+4 Exception raised from create_event_internal at CUDACachingAllocator.cpp:687 (most recent call first)
+5 ...
+6 c10:cuda:CUDACachingAllocator::raw_delete(void *) in /opt/.../torch/lib/libc10_cuda.so
+```
+- 在第 4 个类别中，两个（0.55%）质量问题根源于 Broken GPU Driver，通常需要重启节点或重新安装驱动程序，因为NVIDIAGPU驱动程序无法正常工作。
+
+2）网络
+
+跨多个计算节点的分布式深度学习训练在 Platform‑X 中非常普遍。这些节点在内部与高速网络互连（例如，通过 InfiniBand $^{[9]}$）。我们观察到25个（6.95%）质量问题是由四类网络故障引起的，其中三类与 InfiniBand 相关。 InfiniBand 是“一种用于高性能计算的计算机网络通信标准，具有非常高的吞吐量和非常低的延迟”$^{[9]}$，广泛应用于各种领域基于云的平台。
+
+- InfiniBand Port Down 是最大的类别，包含 6 个（1.67%）案例。这意味着电缆的两个 InfiniBand 主机通道适配器之间没有物理连接，因此会触发NVIDIA 集体通信库（NCCL）$^{[37]}$ 的运行时错误。
+- 第 2 类是 InfiniBand Slowdown（5; 1.39%），这意味着 InfiniBand 适配器非常慢，有时比正常速度慢一个数量级。结果，DL 作业也会变慢甚至卡住。
+- 其他 InfiniBand 故障有 6 个（1.67%），包括适配器初始化失败、平台侧故障驱动程序损坏、写入事务错误和内存注册失败。
+- 第 4 个类别，以太网故障。以太网在 Platform‑X 中也大量使用，用于连接分布式存储和内部服务，并方便用户通过安全外壳协议（SSH）调试失败的作业。此类别有 8 个（2.22%）案例，包括瞬态以太网故障、名称解析错误和对等方重置连接等。
+
+3）节点
+
+Platform‑X 中的计算节点（或简称节点）是一个独特的可调度单元，用于使用GPU、CPU、主内存、磁盘和网络接口卡进行计算。它可以是物理服务器或虚拟机（VM）。由于 Platform‑X使用商品硬件，节点故障在所难免，导致57个（15.83%）质量问题，超过其他两组的总和。
+- 其中 50 个（13.89%）是节点中断，例如操作系统内核崩溃和临时磁盘错误，导致 DL 作业失败或挂起。需要注意的是，临时磁盘被创建并附加到计算节点作为临时存储（例如，一个作业拉取并存储其远程输入数据以供以后快速数据访问）。这一类在节点组中是最大的，远超其他两类。
+- 节点损坏类别包含5（1.39%）个案例。 Platform‑X 支持团队将立即从所属集群中取消提交（即召回）完全损坏的节点，并将其移交给专门的硬件支持团队进行进一步修复。
+- 第 3 类是节点抢占，只有 2 例（0.55%）。用户申请了 spot 节点 $^{[44]}$（即当前未使用的节点，可显着节省成本）；然而，他们并不知道Platform‑X 终止了他们的工作，并为其他支付正常费用的人收回了现场节点。
+
+**【发现2】硬件故障占GPU、网络和计算节点的所有常见原因和结果的近三分之一（28.33%）。
+【启示】硬件故障在深度学习平台中是不可避免的。需要开发和应用主动硬件测试（例如，故障注入$^{[45]}$和压力测试$^{[46]}$）和故障预测（例如，使用机器学习预测模型$^{[40,41]}$）技术。**
+
+#### 2. 平台侧（Platform-side Fault）故障
+
+在本节中，我们描述了平台侧故障的研究，其中包括102个（28.33%）案例，并进一步分为六类。表 17.4.6 显示了详细的分类和分布。
+
+表 17.4.6 平台侧故障统计
+
+||分类|数量|比例|
+|-|-|-|-|
+|1|System Defect 系统缺陷| 37| 10.28%|
+|2|Resource Overload 资源过载 |21| 5.83%|
+|3|Platform Maintenance 平台维护|14| 3.89%|
+|4|Resource Contention 资源争抢|10| 2.78%|
+|5|Transient Service Outage 瞬态服务中断|11| 3.05%|
+|6|Regression 旧伤复发|9 |2.50%|
+||Subtotal| 102| 28.33%|
+
+1）System Defect
+
+系统缺陷是最大的类别，结果为37（10.28%）质量问题。典型缺陷包括：
+
+- 代码错误。例如，Platform‑X 忘记将依赖库打包到官方 Docker 镜像中。再举一个例子，由于存储服务代码中的错误，一些DL作业无法访问分布式存储。
+- 服务配置错误。例如，DL 作业因域名系统（DNS）服务配置错误而失败。
+- 错误的访问控制。如前所述，分布式存储上的输入数据文件夹在没有警告的情况下消失了。
+根本原因是 Platform‑X 错误设置了这样一个文件夹的访问控制，导致同组的另一个同事不小心删除了。
+
+2）Resource Overload
+
+对于某些系统资源，Platform‑X 对用户和 DL 作业没有明确的配额控制。因此，如果用户没有意识到这样的系统设计限制并过度使用资源，就会触发资源过载故障。此类有 21 例（5.83%）。例如，用户试图将所有输入数据加载到主内存中以获得最佳性能。然而，数据太大了，主内存很快就用完了。再举一个例子，用户将他们的临时数据（例如模型检查点、评估结果、软件缓存甚至输入数据）存储在计算节点的本地磁盘上是一种常见的做法。有时，用户忘记清理旧文件，磁盘空间很快就会用完。
+
+3）Platform Maintenace
+
+Platform‑X 定期对 GPU 集群进行平台维护，以进行硬件更换、节点重映像、软件升级和其他任务，这导致了 14 个（3.89%）质量问题。如果用户不进行主动的作业迁移，现有正在运行的DL作业将被 Platform-X 自动终止。偶尔，一些用户不知道维护通知，因此无法持久提交作业。
+
+4）Resource Contention
+
+由于多个 DL 作业可能会竞争计算节点上的相同资源，因此它们可能会相互干扰并触发 Resource Contention 故障。此类别包括 10 个（2.78%）案例。例如，DL 作业意外减速。SRE 发现这样的作业获得的 CPU 时间比平时少得多，因为另一个作业同时创建了太多 CPU 任务。Resource Contention 与上面的 Resource Overload 类似，都可以通过采用更合适的系统设计（例如，应用资源隔离和配额控制）来缓解。
+
+5）Transient Service Outage
+
+第五类是暂时性服务中断，占所有根本原因的 3.05%（11）。例如，由于 SSH 服务暂时不可用，用户无法连接到分配的计算节点。这些服务中断是暂时的，可以在一段时间后自动恢复。但是，我们没有进一步的细节来推断更根本的原因。
+
+6）Regression
+
+Platform‑X 的工具、运行时和服务的旧伤复发（笔者译）导致 9 个（2.50%）质量问题。例如，更新的作业提交工具更改了某些环境变量，从而破坏了向后兼容性。回归来自 Platform‑X 采用的推出政策。目前，新功能和更新正在逐步推出， Platform-X 逐渐扩大部署范围。所以新旧版本都要维护，需要用户注意。一旦发生回归，用户可以将软件或服务回滚到旧版本以缓解问题。
+
+**【发现3】平台侧故障也占所有常见原因的近三分之一（28.33%），其中系统缺陷、资源过载和平台维护是六类中的前三名。
+【含义】平台应改进系统设计和实施，以提供更好的深度学习服务。各种测试技术（例如恶意/压力/回归测试）将有助于尽早暴露平台端故障。**
+
+
+#### 3. 用户侧故障
+
+虽然通常认为⽤户不应该报告⾃⼰造成的任何问题，但我们惊讶地发现有 156 个（43.34%）质量问题实际上是⽤户⽅⾯的故障造成的。我们进⼀步将它们分为五类，并在表 17.4.7 中显⽰详细信息。
+
+表 17.4.7 用户侧（User-side Fault）故障分类
+
+||分类|数量|比例|
+|-|-|-|-|
+|1|Buggy Code|54|15.00%|
+|2|Policy Violation|42|11.66%|
+|3|Improper Permission|35|9.72%|
+|4|Software Incompatibility|14|3.89%|
+|5|Misoperation|11|3.05%|
+||Subtotal|156|43.34%|
+
+1）Buggy Code
+
+第⼀⼤类是 Buggy Code，涉及 54 例（15.00%），占⽤户端故障总数的近⼀半。这些代码错误存在于深度学习程序、Shell 脚本、配置⽂件和⾃定义 Dockerfile 中，其中许多Zhang 等人在实证研究中已经提到$^{[27]}$。例如，许多错误来自“本地和平台执行环境之间的差异”。$^{[27]}$
+
+下面显示了一个 DL 作业为 TensorBoard $^{[47]}$ 可视化访问了一个不存在的本地文件夹。用户似乎忘记调整代码并在 Platform‑X 上使用路径。
+
+```
+1 ...
+2 files = $^{[f for f in listdir(logdir) if isfile(join(logdir, f))]}$
+3 FileNotFoundError: $^{[Errno 2]}$ No such file or directory: '˜/tensorboard/xxx'
+4 ...
+```
+
+由于 Platform‑X 执行环境的复杂性，用户应该采用更具防御性的编程来处理各种可能不会暴露在其本地开发机器上的潜在故障。例如，我们注意到一项作业因意外格式的异常数据而崩溃。
+
+更好的做法包括在提交作业之前主动清理数据集和为本地测试采样数据。一些工作依赖外部服务，却忽略了对服务不可用的适当处理；例如，他们无法拉取外部 Docker 镜像、模型或数据集。 Hugging Face$^{[12]}$ 为用户提供了从“机器学习中的参考开源”构建最先进的AI应用程序的工具，其预训练模型和数据集存储在自己的存储库中。
+
+下面显示了错误网关故障，其中 DL 作业无法下载所需的拥抱面模型。为了降低外部服务不可用的概率，鼓励用户切换到等效的内部服务（例如，提前将 Hugging Face 模型上传到内部分布式存储）。
+
+```
+1 ...
+2 raise HTTPError(http_error_msg, response=self)
+3 requests.exceptions.HTTPError: 502 Server Error: Bad Gateway for url:https://huggingface.co/xxx.model
+4 ...
+```
+
+我们进一步发现了一些 Zhang 等人没有提到的性能错误$^{[27]}$，因为他们只研究了深度学习程序失败。例如，一个作业从分布式存储中读取了大量的小数据文件，严重拖慢了训练过程。作为另一个示例，由于线程之间存在潜在争用，多 GPU 训练作业运行非常缓慢。
+
+我们还注意到一些软件挂起错误$^{[48,49]}$，这些错误使作业无处可去；例如，一项作业在源代码中错误配置了 InfiniBand，挂在了 NVIDIA NCCL通信上。
+
+2）Policy Violation
+
+Platform‑X 强制执行多项政策规则，以保证用户更恰当、更高效地使用宝贵的平台资源。 Platform‑X 虽然提供了政策说明文档和培训课程，但部分用户仍不了解这些规则，从而引发Policy Violation故障，导致质量问题42起（11.66%）。此类别是第二大类别，约占所有用户侧故障的四分之一。例如， Platform‑X 会自动终止 GPU 在指定时间段内空闲的用户作业，以减少资源浪费并最大限度地提高平台利用率。
+
+我们还注意到一些用户向 Platform‑X 提交交互式深度学习程序（例如， Jupyter $^{[50]}$ notebooks）用于开发和测试目的。由于非确定性交互，无法提前知道 GPU 的使用时间和使用时长。最后，Platform-X 因闲置时间过长而终止了这些交互式作业。其他违反策略规则包括，例如，平台X临时存储上的数据在几天后到期（因此用户需要尽快将它们移动到持久存储）和DL作业没有启动与某些内部服务的太多连接。违反后者会触发服务节流并导致作业放缓甚至服务终止。
+
+3）Improper Permission
+
+用户及其 DL 作业需要适当的权限才能访问 Platform‑X 的资源；否则，会引发 Improper Permission 错误，导致 35（9.72%）个质量问题。例如，用户无法向某个GPU集群提交任何作业。事实上，他的集群访问请求仍在处理中，因此用户此时没有访问权限。另一个例子是，由于缺少正确的凭据，DL 作业无法从中心拉取 Docker 镜像。
+
+4）Software Incompatibility
+
+第四类是软件不兼容，由14个（3.89%）案例组成。随着越来越多的应用领域采用深度学习，与 DL 相关的软件，例如 NVIDIA 运行时、框架、库和优化工具包，最近一直在快速发展。但是，由于它们是由不同的社区独立开发的，因此不匹配的组件之间可能会出现不兼容的情况。
+
+例如，由于标准 DL Docker映像使用的 NVIDIA CUDA 运行时版本低于本地开发版本，因此作业卡住了。通常，DL 作业会在初始化阶段安装依赖库。如果用户忘记明确指定库版本，他们可能会获得尚未经过自己测试的最新软件，这可能会引发软件不兼容。例如，一个作业安装了一个较新的不兼容版本的 Microsoft DeepSpeed $^{[51]}$（一个优化工具包），然后由于网络吞吐量的下降而明显变慢计算节点。为了减少软件不兼容，用户需要更深入地了解各种 DL 软件组件，并使用预装所有依赖库的自定义 Docker 镜像。
+
+5）Misoperation
+
+用户操作不当造成质量问题的原因有 11 起（3.05%），原因可能是用户不熟悉操作流程。
+
+例如，用户在门户网站上查询信息时应用了错误的过滤器，因此收到了意想不到的结果。另一个例子是用户无意中错误地删除了他的工作区。工作区提供了“一个集中处理您创建的所有工件的地方”$^{[52]}$。因此，用户在不知情的情况下丢失了所有培训工作的历史记录。
+
+**【发现4】用户端故障占所有常见原因的五分之二以上（43.34%），其中代码错误、违反策略和权限不当是五类中的前三名。
+【启示】用户应该改进深度学习代码，参考文档，参与训练，以减少自己犯的错误。可以开发静态分析工具来尽早自动检测用户端故障。**
+
+### 17.4.7 从质量问题到缓解措施
+
+站点可靠性工程师（SRE）有责任在报告新的质量问题时迅速采取缓解措施。缓解措施的目的是在尽可能短的时间内使受影响的工作恢复工作或恢复 Platform-X 的服务；否则，业务将受到不利影响，宝贵的资源将被严重浪费。缓解措施通常是一种变通方法，而不是最终修复解决方案，因为后者需要长时间的彻底调查、无错误实施和广泛测试，因此可能无法承受。
+
+在本节中，我们研究了 SRE 采取的常见缓解措施，并将它们分为十类。表 17.4.8 显示了分类详细信息。请注意，22/6.11% 的质量问题缺乏关于如何缓解的明确细节；因此，我们将他们的缓解措施标记为其他。
+
+表 17.4.8 缓解措施
+
+||分类|数量|比例|
+|-|--|-|-|
+|1|Job Resubmission |125 |34.72%|
+|2|User Code Improvement |89 |24.72%|
+|3|Operation Correction| 26| 7.22%
+|4|System Reconfiguration |23| 6.39%|
+|5|Software Rollback| 22| 6.11%|
+|6|Automatic Healing |22| 6.11%|
+|7|System Hotfix |19| 5.28%|
+|8|Node De-commission| 5| 1.39%|
+|9|Job Killing |4| 1.11%|
+|10|Quota Increase |3| 0.84%|
+|11|Others∗ |22| 6.11%|
+||Total |360| 100.00%|
+
+1）Job Resubmission
+
+工作重新提交是最大的类别，包含125（34.72%）个案例。正如我们在第VI节中看到的，许多作业失败和速度减慢是由各种硬件和平台端故障引起的，其中大多数实际上只影响一个或几个计算节点。一旦SRE识别出一个故障节点，或者Platform‑X 自动检测到一个节点，它就会从所属集群中取消提交以进行离线修复。因此，在不修改任何配置和参数的情况下重新提交受影响的作业将很可能避免出现故障的节点并成功完成作业。
+
+2）User Code Improvement
+
+用户代码改进是第二大类别，适用于89（24.72%）个质量问题。很多是用户端的问题，确实不应该报告给平台支持团队。但是，为了不妨碍我们的业务，SRE积极帮助用户完善他们的代码、访问权限和提交参数。例如，SRE指示用
+
+户针对 InfiniBand 相关问题增加源代码中的 NCCL 超时值。对于部分由 Resource Overload和Resource Contention引起的问题，代码改进也是一种有效的缓解方法。
+
+3）Operation Correction
+
+26（7.22%）质量问题由于误操作、违反政策和不当许可可以通过操作纠正来缓解。例如，正如我们提到的，用户应用了错误的查询过滤器。SRE指导用户如何在 Web 门户上正确查询信息并建议正确的过滤器。
+
+4）System Reconfiguration 
+
+包括 23 个（6.39%）质量问题，主要由 Resource Overload、 Policy Violation 和 Improper Permission 引起。SRE 需要重新配置访问权限、策略规则或服务参数。例如，一个问题报告说存储用完了。为了缓解它，SRE 和集群管理员增加了总存储量并执行了数据清理。
+
+5）Software Rollback
+
+由软件不兼容、回归和系统缺陷（一个案例）引起的 22 个（6.11%）质量问题通过软件回滚到最后一个有效版本得到缓解。对于系统工具、组件和服务， Platform‑X 保留了几个最新的工作版本。
+
+6）Automatic Healing
+
+一些服务中断和硬件故障是暂时的，或者可以由 Platform‑X 自动恢复。因此，有 22 个（6.11%）质量问题通过自动修复得到缓解，这意味着用户无需执行特定操作。
+
+7）System Hotfix
+
+许多系统缺陷可能表现出潜在的广泛影响，并且没有简单的缓解措施。因此， Platform‑X 和其他系统服务的支持团队共同努力，尽快交付系统修补程序。例如，由于轻微的不兼容问题，操作系统升级导致存储服务无法正常工作。支持团队很快修复了不兼容问题，然后应用了系统修补程序。该类共计 19 例（5.28%）。请注意，修补程序在成为正式系统补丁之前需要进一步验证和压力测试。
+
+其余三个较小的类别是：
+
+8）节点停用（5/1.39%），立即从集群中消除故障计算节点，仅适用于节点损坏故障。
+9）Job Killing（4/1.11%），它减轻了用尽所有资源并停止进一步提交作业的僵尸作业。
+10）Quota Increase（3/0.84%），要求用户增加某些资源（如主内存）的配额，以解决 Resource Overload 和Resource Contention 故障。
+
+**【发现5】有十类缓解措施。作业重新提交（34.72%）和用户代码改进（24.72%）缓解了总质量问题的五分之三以上。
+【含义】可以开发基于历史统计数据的自动推荐工具来自动化和加速缓解过程。**
+
+### 17.4.8 讨论
+
+#### 1.	本研究的一般性
+
+我们的研究仅在 Microsoft 进行；然而，我们认为所选的深度学习质量问题是普遍存在的，研究结果可以推广到其他DL 平台，例如 Microsoft Azure Machine Learning $^{[6]}$、 Amazon SageMaker $^{[7]}$ 和 Google Cloud AI $^{[8]}$。关键原因是 Platform‑X 与其他平台之间的双重相似性：
+
+- Platform‑X是使用广泛采用的硬件、系统架构和软件堆栈构建的$^{[26]}$、$^{[53]}$、$^{[54]}$，与其他平台类似平台。此外，Platform‑X 采用了类似的作业管理机制（例如，提交和执行）。
+- Platform‑X 上运行的 DL 作业采用标准的编程范式。例如，它们使用 Python 语言、流行框架（例如 ONNX $^{[33]}$、PyTorch $^{[10]}$ 和 TensorFlow $^{[11]}$）和库（例如 Fairseq $^{[35]}$ 和 Microsoft Deep Speed $^{[51]}$）进行编程和随机算法。这些工作还针对图像识别、自然语言处理和游戏等常见任务。
+
+研究人员还观察到类似的质量问题和根本原因。之前的工作$^{[38,39,55]}$发现“GPU是故障最严重的前3名硬件之一，GPU内存对不可纠正的错误比主内存更敏感”，$^{[41]}$这与我们的发现一致。OPT（Open Pre‑trained Transformers）开发的编年史 $^{[56]}$描述了 Meta（前身为 Facebook）研究人员如何与各种质量问题作斗争。许多来自硬件故障（例如，InfiniBand 问题和 GPU ECC 错误），导致“每天约有 2 台机器停机”$^{[56]}$ 曾经有一个严重的平台端故障：“云提供商的支持团队在2021年12月21日不小心删除了我们的整个集群。”$^{[56]}$对于用户端故障，现有的与 DL 相关的实证研究$^{[23,27,31]}$提到了一些导致作业崩溃和减速的代码错误。
+
+#### 2. 未来的研究方向
+
+基于我们的研究，我们提出了以下未来的研究方向。
+
+1）工具支持
+
+- 硬件故障预测
+
+    近三分之一（102/28.33%）的质量问题是由GPU、网络和计算节点的故障引起的。我们可以训练机器学习模型来预测哪个硬件设备会发生故障以及发生故障的时间。例如，刘等人$^{[41]}$使用机器学习技术（例如，LSTM $^{[57]}$、1D‑CNN $^{[58]}$ 和集成学习 $^{[59]}$）根据各种 GPU 和机器参数（例如温度、机器正常运行时间和 GPU）来预测 GPU 错误利用率/类型/位置。
+
+- 挂起分析器
+
+    虽然作业挂起只占质量问题的7.50%（27），但对于 SRE 来说诊断和解决这些问题是相当具有挑战性的。与之前的软件挂起（即无响应或冻结）$^{[48,49]}$不同，作业挂起深入涉及底层 NVIDIA 运行时（即NCCL）和硬件（例如 GPU 和 InfiniBand）。例如，当通信节点数量增加时 NCCL 中存在潜在的死锁。我们可以开发静态和动态挂起分析器，以在提交作业之前主动减少此类问题碰撞容忍度。
+
+- 崩溃容忍
+
+    198（55.00%）质量问题是作业崩溃；因此，最新的训练进度（即模型权重和偏差）将永久丢失。一种常见但简单的防止崩溃的方法是定期保存模型检查点。然而，DL框架的内置模型检查点是初步且低效的。我们可以使用频率自适应性 $^{[60,61]}$增量检查点 $^{[62]}$、异步 $^{[61,63]}$和高性能序列化$^{[64,65]}$来实现更有效的模型检查点。此外，弹性训练$^{[66...68]}$也是一种有用的技术，可以实现动态作业缩放以防止各种崩溃。
+
+- 代码顾问
+
+    在我们的研究中，我们已经看到许多质量问题是由用户代码错误、不当许可和违反政策引起的。因此，我们可以开发基于静态分析的代码顾问，主动检测用户程序、Shell 脚本、Dockerfile 和配置/凭证文件中的各种问题。此外，这些代码顾问可能会提供高级修复建议或自动程序修复功能。
+
+2）平台改进
+
+- 故障感知作业调度
+    在检查所有问题记录并与一些SRE讨论后，我们观察到某些特定的计算节点在重负载下具有更高的中断概率。目前，深度学习平台主要根据所需资源为作业分配节点。这样的平台可以从计算节点的历史故障数据中学习，并将故障意识整合到它们的作业调度程序中。未来可能的工作是使平台能够估计作业工作量并将长时间运行的作业调度到更稳定的节点而不是容易出错的节点。这样，可以减少潜在的工作问题。
+
+- 平台测试
+
+    一半以上的质量问题是由于硬件和平台端的故障。由于计算用于深度学习的设备（例如 GPU 和 TPU）、高速网络（例如 InfiniBand）和软件（例如 Kubernetes 和 NVIDIA 运行时）正在快速发展，平台需要更先进和更全面的测试方法。例如，Microsoft SuperBench $^{[46]}$ 使用代表性的训练工作负载来验证AI基础设施，并检测到许多新的硬件/平台问题。我们还可以采用压力测试$^{[69]}$、故障注入$^{[45]}$、$^{[70]}$和模型检查$^{[71]}$来更彻底、更有效地测试DL平台。
+
+
+*由于篇幅有限，17.4.9 和 17.4.10 略，参考文章链接没有列出，有兴趣的读者可以阅读原文。*