[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 Spataro提到了Windows终端。
我想尝试使用Windows终端连接到Linux和Windows系统。

Julia White 对最新的 Azure 服务和发展趋势进行了详细的讲解。
尤其是在谈到 Azure DevOps 时，她语气激动人心，重点介绍了 Azure Kubernetes。Alex
演示了 HoloLens 2，他身旁的虚拟 Alex 感觉非常逼真。
如果下次有机会，我一定要亲自体验一下 HoloLens 2！

参与会议

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

说实话，我之前对 Kubernetes 还不太了解，但听完这次讲座后，
通过讲解和演示，我对它有了更清晰的认识。
讲解非常易懂，也提到了重要的设置要点，所以我打算再复习一下相关资料！
最后，您提到使用 Kubernetes 最重要的是首先要彻底理解它的工作原理……我觉得您说得对。

HashiCorp Terraform Azure 提供程序教程

在短短20分钟的讲解中，他介绍了Terraform，它的优势以及使用便捷性。
我们公司的寺冈先生很喜欢Terraform，这次讲解是对他之前公司内部学习内容的复习。他说
，一开始他觉得在HCL中创建配置文件很麻烦，但现在他认为，如果没有Terraform，构建项目反而会更麻烦。

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

这里是ZOZOTOWN，
我个人一直对此心存感激。

ZOZOTOWN 似乎拥有许多本地服务器，随着服务的增长，服务器数量也在增加，为了
始终有足够的服务器来处理销售活动，导致了较高的运营负荷。

采用 Kubernetes 的原因有三：
1）能够灵活地增减单元数量；
ZOZOTOWN 定期进行销售，因此需要具备灵活的扩展能力；
2）应用程序部署较为复杂，因此希望将其容器化；
3）具备自动扩展能力
。采用 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 的公司。
富士胶片软件有限公司
正在为其
照片和设计管理及共享云服务 IMAGE WORKS我们请他们分别从工程师和管理者的角度来谈谈。

从工程师的角度来看

■ 实施 NoOps 之前
：我们希望减轻发布工作的负担。
系统只能在深夜停机维护。随着服务器数量的增加，发布工作量也随之增加。
任何人的大规模操作都会对整个服务构成风险，难以调查操作者及其行为，也难以进行恢复。

■您想用 NoOps 做什么？
・减轻发布工作的负担。
使用 AppService 和 Azure Functions（这就是 Azure 的用武之地）。
使用 Azure DevOps 实现构建和部署自动化。

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

■ NoOps 的优势：
・我想减轻发布工作的负担。・
无需停止服务即可随时发布。・
一键发布到生产环境。

・减少应对故障所需的人工时。
即使发生意外错误，整个服务也不会停止。
其他地区的备用机器将保持运行，从而为恢复响应留出充足的时间。

■ NoOps 的缺点
・我想减轻发布工作的负担。
但有 10% 的失败概率，所以需要确认。
即使失败，状态也会显示为正常，因此可视化确认至关重要。

・为了减少应对故障所需的人工时
，流程划分得越多，监控和检查的项目就越多。
开发人员和运维人员必须充分了解流程的划分程度。

虽然随时发布非常方便，但这
并非全是好事。
的确，需要检查的项目越多，花费的时间就越长。

管理者的视角

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

您提到，最初只需将成本转移到其他领域即可。
具体来说，
在实施 NoOps 之前
，业务成本占 60%，维护成本占 30%，改进成本占 10%。
在 NoOps 实施初期
，业务成本占 60%，维护成本占 20%，改进成本占 20%
。NoOps
的目标是将
业务成本降低至 70%，维护成本降低至 10%，改进成本降低至 20%，
这意味着降低维护成本并将其转移到业务成本中。

经查明，无法按以下方式降低总成本：
业务成本（40%）、维护成本（10%）、改进成本（10%）。

SRE团队组织

毕竟，计划赶不上变化。
所需的技能和思维方式与传统的开发/运维截然不同。
不可能面面俱到地完成从开发到支持的所有工作。
你不能自己编写程序（运维人员的观点）
。功能开发仍然是重点（开发人员的观点）。
我经常听到这样的说法，但要完全按照SRE的模式来做确实很难。

・是引进现有球员还是培养新球员？
他将世界顶级足球队比作日本职业足球联赛（J联赛），并表示如果球员能力不匹配，简单地模仿顶级联赛的战术是行不通的。
我明白了……这个比喻非常容易理解。

团队组成仍在探讨中。

朝日专业管理株式会社
伊藤忠技术解决方案株式会社
我们所做的：
完全本地化管理、
自动恢复架构、自主
运行

即使采用完全托管的架构，运营挑战依然存在。
运营方面，我们经常听到这样的抱怨：
“客户的工作越来越自动化，但我们的工作却还没有……”
⇒ [挑战] 让我们尝试 RPA
⇒ [结果] 成功实现日常任务自动化
⇒ [挑战] 需要维护机器人执行环境，而且经常出现处理延迟。
我对 RPA 了解甚少，但它似乎在日常任务（例如 Excel 工作）中扮演着重要角色。
因此，NoOps 不仅仅是调整基础设施配置那么简单。

“根据系统使用情况调整资源”
⇒ [挑战] 实现可扩展架构
⇒ [结果] 减少高峰使用期间的工作负载

我感觉无法应用于运行系统的可扩展架构很常见

概括

这篇文章最终写得相当长，
可见这次活动内容有多么丰富。
我还参加了以下几个环节，每个环节都非常有趣，让我受益匪浅。
“如何将本地数据库迁移到 Azure SQL 数据库？——倍乐生新研泽米案例研究”、
“百年寿命时代的 PDCA——运用 PDCA 进行职业和工作方式改革的新旧方法”、
“面向 AWS 工程师的 Azure 无服务器架构”。

第一天结束时，举办了一场盛大的派对！
我们一边享用各种美食和甜点，一边沉浸在热闹的派对氛围中。DJ
非常专业，音乐也很有夜店范儿，让我感觉仿佛置身于夜店之中。