[Microsoft de:code 2019] 我参加了 de:code 2019！

2019.07.17

其他的

0.1 主题演讲

1 参与会议

你好。

最近，Beyond 受邀参加了微软举办的 de:code 2019 大会！
我想和大家分享一下我参加的会议以及 de:code 2019 派对的感受。
由于我是一名基础设施工程师，所以我主要参加了面向基础设施而非开发人员的会议。

主题演讲

我们聆听了以下人士的演讲：
平野拓哉（微软日本有限公司）
、贾里德·斯帕塔罗（微软公司
）、朱莉娅·怀特（微软公司）
和亚历克斯·基普曼（微软公司）。
您可以通过以下链接在 YouTube 上观看主题演讲：
https://youtu.be/GtVcDo1G8r8

平野先生主要谈到了人工智能，提到了一些项目，例如用于测量阿修罗像年龄的设备，以及用于创建3D可视化模型以修复被火灾损毁的巴黎圣母院的项目。他
还提到要拓展开源模式，与红帽OpenShift和VMware合作开发。

Jared Spatarou提到了Windows终端。
我想尝试使用Windows终端，并测试连接到Linux和Windows系统。

Julia White 对最新的 Azure 服务和发展趋势进行了详细的讲解。
特别是她关于 Azure DevOps，特别是 Azure Kubernetes 的演讲，真是精彩绝伦。Alex
演示了 HoloLens 2，他旁边的虚拟 Alex 感觉非常逼真。
如果我有机会再去，我一定要亲自体验一下 HoloLens 2！

参与会议

了解 Azure Kubernetes 服务 (AKS) - 从开发人员的角度了解 Kubernetes 的基础知识

说实话，即使像我这样之前对 Kubernetes 一无所知的人，
听完这场讲座后也对它有了更深入的了解。讲座中讲解了 Kubernetes 的概念和功能，并辅以演示。
讲解非常通俗易懂，甚至还介绍了一些配置要点，所以我很想再复习一下相关资料！
最后，他们提到使用 Kubernetes 最重要的是首先要彻底理解它的工作原理，我觉得这完全正确。

HashiCorp Terraform Azure 提供程序教程

在短短 20 分钟的讲解中，我们了解了 Terraform，包括它的优势和便捷性。
我们的员工 Teraoka 是 Terraform 的忠实拥趸，这次讲解也算是对他之前内部学习会上所讲内容的复习。他
最初觉得用 HCL 创建配置文件很麻烦，但现在他说，如果没有 Terraform，他根本不想构建系统。

在 ZOZOTOWN 负责生产环境中的 Kubernetes 管理

那是ZOZOTOWN。
我个人一直都在使用他们的服务。

ZOZOTOWN 显然使用了大量的本地服务器，
他们面临的挑战似乎是随着服务增长，所需的服务器数量不断增加，从而造成了很高的运营负担，以及需要不断维护足够的服务器来处理销售。

采用 Kubernetes 的原因有三：
① 服务器数量可灵活扩展
：ZOZOTOWN 销售稳定，因此需要具备灵活的扩展能力；
② 应用部署流程繁琐，因此希望将其容器化；
③ 支持自动扩缩容
。采用 Kubernetes 的目的是通过确保系统稳定运行、减轻运维负担，并面向微服务架构的多云迁移进行设计，从而提高 ZOZOTOWN 的可用性。

显然，该系统更换工作从 2017 年 8 月开始，目前有五名成员参与，并且他们仍在招募新成员。

关于 Kubernetes 的运行，确实有很多方面可以简化操作，但需要记住的知识范围很广，从底层到高层都有涉及。

当被问及为何选择微软 Azure 时，微软全面的统一支持似乎是一个主要因素。能够
根据需要多次联系支持团队、与微软工程师解决问题，甚至获得本地部署问题的建议，这极具吸引力。
事实上，能够联系支持团队并获得快速响应，通常比自行查找信息更快、更准确，这是一个显著的优势。

DevSecOps 时代的日志管理与安全

本次讨论从DevOps的角度探讨了日志管理。
在DevOps中，需要管理三种类型的日志：开发日志、运维日志和审计日志。
我本人没有DevOps方面的经验，但日志管理对于MSP（托管服务提供商）来说也至关重要。
毕竟，如果不保留日志，就只能查看事件响应信息以及事件发生的时间点，而且也仅限于当时的情况。

我们学习了三种日志的关键要点：开发日志、运行日志和审计日志。

开发日志
和开发人员执行的任务
。在自动化测试环境中，开发日志可能无需单独设计，因为它们已包含在开发环境中
。开发日志无需长期保存，但最好保留一段时间，以便分析开发人员的工作方式。⇒
即使开发完成后，保留工作记录也有助于学习和成长，从而提高开发效率。

操作日志
设计一个“仪表盘”和一个“自助服务界面”，使操作员能够根据
。操作员的任务也应记录为工作日志
。操作任务应遵循“变更管理”流程，并且系统应设计为支持回滚。⇒
仪表盘非常有用。
只需一眼，即可确定问题原因，有时甚至能准确找到原因。⇒
保留工作日志也很重要。
如果工作导致问题，回滚可能需要很长时间，甚至可能无法回滚。最好
事先将工作流程记录为程序。

审计日志
和报告，必须准备详细的日志信息。
在安全审计中，仅仅说明数据已加密是不够的；还需要解释授权人员正在以适当的方式处理数据。
必须使用远程日志记录和其他方法来证明日志的客观性。

实践中的 NoOps——NoOps 真的会改变我们的工作方式吗？

我们从一家大型公司了解到，他们是如何将 NoOps（No Uncomfortable Ops）方法付诸实践的。

系统运行和维护中令人不快的方面：
1. 实现不影响用户体验的系统运行和维护
（故障导致的停机、计划内停机、高负载期间的性能下降等）；
2. 最大程度地减少系统运行和维护中的繁琐
（发布流程、补丁应用、资源监控、备用等）；
3. 优化系统运行和维护成本
（避免资源浪费、保证质量、避免加班、合理利用人员等）。

“辛劳”似乎指的是“劳动”或“艰苦的工作”。
那些需要人工操作、重复性工作、可以自动化、具有战术性、缺乏长期价值，并且相对于服务增长具有 O(n) 时间尺度的任务
。

有人告诉我，一个系统由用户“获得的价值”和提供者“承担的负担”组成。
当然，作为运营负责人，
理想的情况是最大化“价值”并最小化“负担”。
但实际上，往往是“价值”很小而“负担”很大。

所以，NoOps 的核心在于减轻运维带来的“不必要的”负担。
我从一开始就对这个概念很感兴趣，因为我所在的团队致力于减少浪费、简化运营流程。

NoOps 似乎有两个方面：“防御”和“进攻”。
“防御”NoOps 的特点
：监控和通知的自动化
、重试的自动化
、配置更改的自动化
、方法的标准化
以及状态
（和其他 SRE 活动）的可视化。

“主动式”无运维（NoOps）的特点
是容器
、微服务
和无服务器架构
。其理念是设计本质上不需要运维的系统。

接下来，我们采访了一家正在实际实施 NoOps 的公司。
富士胶片软件有限公司
用于管理和共享照片及设计的云服务“IMAGE WORKS”正在其
他们从工程师和管理者的角度分享了他们的观点。

从工程师的角度来看

■NoOps之前
——我们希望减轻发布工作的负担。
系统只能在夜间停机维护，而随着服务器数量的增加，发布工作量也随之增加。
一个人进行大规模操作会给整个服务带来风险，而且调查操作原因和恢复工作都非常困难。

■我们希望通过 NoOps 实现的目标
：减少发布运维的工作量。
利用应用服务和 Azure Functions（这就是 Azure 的作用所在）。
使用 Azure DevOps 实现构建和部署自动化。

- 我们希望减少应对故障所需的工作量
。- 我们希望按进程分离服务，而不是将功能合并到单个应用服务中。-
我们希望在另一个区域拥有一台备用机器，以便随时进行切换。

■ 无运维的优势：
- 减少了发布工作量 -
能够随时发布而无需停机 -
一键发布到生产环境

我们希望减少应对故障所需的工作量。
即使发生意外错误，整个服务也不会停止运行。
位于其他区域的备用机器将继续运行，从而为我们争取更多恢复时间。

■ NoOps 的缺点是什么
？ - 我们原本想减少发布工作量。 -
它大约有 10% 的失败率，因此验证是必要的。 -
即使失败，状态仍然显示为正常，所以可视化验证至关重要。

为了减少处理故障所需的工作量
流程划分得越细
。开发人员和运维人员必须了解每个环节的处理流程。

虽然随时发布非常方便，但
它并非没有缺点。
当然，需要检查的项目越多，就意味着需要花费更多的时间。

管理者的视角

不要急于求成，以免影响 NoOps 的结果。

最初，他们表示这只是一个成本分配的问题。
具体来说，
在实施 NoOps 之前
，业务相关成本占 60%，维护成本占 30%，改进成本占 10%。
在 NoOps 实施初期
60%，维护成本占 20%，改进成本占 20%
占
的目标是将
业务相关成本降至 70%，维护成本降至 10%，改进成本降至 20%。
这意味着降低维护成本，并将其重新分配给业务相关成本。

他们表示，按以下方式降低总成本是行不通的：
业务相关成本（40%）、维护相关成本（10%）、改进相关成本（10%）。

SRE团队组织

事情并非总能按计划进行。
所需的技能和思维方式与传统的开发/运维截然不同。
不可能包揽从开发到支持的所有工作。
我不会写程序（一位运维人员的观点）。
功能开发仍然是最吸引人的部分（一位开发人员的观点）。
我经常听到这样的说法：要达到SRE手册上描述的目标并非易事。

我们应该引进现有球员还是培养新球员？
他以世界顶级足球队和日本职业足球联赛（J联赛）为例，解释说如果球员能力不足，简单地模仿顶级联赛的战术是行不通的。
我明白了……这确实是一个非常清晰的例子。

团队组成仍在探讨中。

朝日Pro Management株式会社和
伊藤忠技术解决方案株式会社：
我们的工作
——从本地部署到完全托管
——自动化恢复架构
——自主运行

即使采用完全托管的架构，运维挑战依然存在。
运维团队表示：
“客户的任务自动化程度越来越高，但我们自己的任务却没有……”
⇒ [挑战] 让我们尝试使用 RPA
⇒ [结果] 成功实现日常任务自动化
⇒ [挑战] 需要维护机器人执行环境，并且经常出现处理延迟。
我对 RPA 了解不多，但它似乎对日常任务（例如 Excel 工作等）非常有用。NoOps
不仅仅是更改基础设施配置。

“根据系统使用情况调整资源”
⇒ [挑战] 实现可扩展架构
⇒ [结果] 高峰使用期间降低工作负载
⇒ [问题] 尚未应用于运行中的系统
。我感觉可扩展架构在 NoOps 中很常见。

概括

这篇文章写得有点长，
因为这次活动内容非常丰富。
我还参加了以下几个环节，都非常有趣，信息量很大：
“如何将本地数据库迁移到 Azure SQL 数据库？——来自 Benesse Shinkenzemi 的案例研究”、
“百年寿命时代的 PDCA——一种既古老又新颖的 PDCA 实践方法，用于职业和工作方式改革”、
“面向 AWS 工程师的 Azure 无服务器架构”。

第一天结束时举办了一场精彩绝伦的派对！
我们一边享用着各种美食和甜点，一边沉浸在热闹的派对氛围中。DJ
非常专业，音乐棒极了，感觉就像置身于夜店一样。