【微软de:code 2019】我们参加了de:code 2019！

你好。

日前，Beyond受微软邀请参加de:code 2019！
我想跟大家分享一下我参加的会议和 de:code 2019 聚会的印象。
这次，由于我是一名基础设施工程师，所以我主要观看针对基础设施而不是开发人员的会议。

主题演讲

我们收到了以下人士的来信。
Takuy​​a Hirano 先生（微软日本有限公司）
Jared Spataro 先生（微软公司）
White 先生（微软公司）
Alex Kipman 先生（微软公司）
主题演讲可通过以下链接在 Youtube 上观看。
https://youtu.be/GtVcDo1G8r8

平野先生主要谈论人工智能，他正在研究一些项目，例如测量阿舒拉雕像年龄的设备和创建 3D 视觉模型来修复被大火烧毁的巴黎圣母院的项目。
此外，为了拓展开源路线，与RedHatOpenShift和VMware的协作和联合开发似乎正在取得进展。

Jared Spataro 谈论了 WindowsTerminal。
我想尝试使用 Windows 终端并尝试在 Linux 和 Windows 上进行连接。

Julia White对Azure的最新服务和趋势进行了详细的讲解。
特别是当他谈到Azure DevOps时，他的语气非常兴奋，主要关注的是Azure Kubernetes。
Alex正在演示HoloLens2，身旁的虚拟Alex感觉非常真实。
如果我再去那里，我想尝试一下 HoloLens2！

参与环节

了解Azure Kubernetes Service（AKS）的机制~从开发者的角度了解Kubernetes的基础知识~

老实说，Kubernetes 到底是什么？
Kubernetes 是什么以及有了更深入的了解
说明非常容易理解，并且包含了要设定的要点，所以我想再次复习一下材料......！
正如您最后所说，为了使用 Kubernetes，最重要的是首先彻底了解它是如何工作的……我认为您是对的。

HashiCorp Terraform Azure 提供程序教程

在短短 20 分钟的会议中，他解释了 Terraform、它的好处以及它的便利性。
我们公司的 Teraoka 喜欢 Terraform，这是对他之前在内部学习课程中学到的知识的一个很好的回顾。
他说，一开始他觉得用 HCL 创建配置文件很麻烦，但现在他说不用 Terraform 构建更麻烦。

管理 ZOZOTOWN 中的 Kubernetes 实际生产运营

那个佐佐镇。
就我个人而言，我始终感激你。

ZOZOTOWN似乎有很多本地服务器，并且随着服务的增长，服务器数量增加，并且
不断准备能够承受销售的服务器数量，这导致运营负载很高。

我选择Kubernetes的原因是：
（1）灵活增加/减少
ZOZOTOWN持有定期销售的单位数量，因此需要能够灵活扩展（
2）我想使用容器，因为运行所需的设置

) Kubernetes可以自动扩展，。

显然，自 2017 年 8 月以来，System Replace 已拥有 5 名成员……他们目前正在寻找成员。

关于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之前
- 想要减少发布工作负载
系统只能在深夜停止，并且随着服务器数量的增加，发布工作也会增加，
对整个服务造成风险。谁做了什么也很难恢复。

■您想用NoOps做什么

使用AppService和AzureFunction
来减少发布工作的负载使用AzureDevOps自动化构建和部署

- 希望减少响应故障所需的时间
- 拆解每个进程的服务，而不是将功能集中在一个 AppService 中
- 将备用机放在另一个区域，以便可以随时切换

■NoOps 的优点
- 我想减轻发布工作的负担 我可以
随时发布而无需停止服务 我可以
通过一个按钮发布到生产环境。

・我想减少应对故障所需的工时。
即使发生意外错误，整个服务也不会停止。由于
另一个地区的备用机正在运行，因此有更多的恢复时间。

■NoOps的问题
- 我想减轻发布工作的负担。
由于有10％的
失败机会，因此需要进行确认，因此即使失败状态也会正常，因此目视确认至关重要。

・想要减少处理故障所需的工时。
流程分离得越多，需要监视和检查的项目就越多。开发人员
和操作人员必须相应地了解流程流程。

能够随时发布东西变得非常方便，但另一方面
，这也并非都是好事。
确实，您需要检查的项目越多，花费的时间就越多。

经理的视角

不要急于获得 NoOps 的结果

起初，你说你唯一要做的就是搬到一个更昂贵的地方。
具体来说，
在NoOps举措之前，
业务成本（60%）、维护成本（30%）、改进成本（10%）、
初始
业务成本（60%）、维护成本（20%），其中包括

NoOps的目标
业务成本（70%）、维护成本（10%）、改进成本（20%），
降低维护成本，将其转化为业务成本。

据说，如下所示，降低总体成本是行不通的。
业务成本（40%）、维护成本（10%）、改进成本（10%）

关于SRE团队的构成

- 毕竟事情不会按计划进行。
所需的技能和心态与传统的开发/运营不同。

不可能编写一个
从开发到支持都需要的 。功能开发是毕竟明星（Dev成员的意见）
我经常听到这样的说法，据说很难达到SRE书上说的那样。

- 转换或开发新的？
谈到世界顶级球队和J联赛，他表示，即使只是模仿顶级联赛的战术，如果不与球员的能力相匹配，也是行不通的。
我明白了...这是一个非常容易理解的例子。

看来团队构成还在探索中。

Asahi Pro Management Co., Ltd.
伊藤忠技术解决方案有限公司
我们所做的
- 从内部进行全面管理
- 自动恢复架构
- 自主操作

即使是完全托管的架构似乎也存在运营挑战。
从运营方面来说
，“客户的运营越来越自动化，但我们自己的运营还没有自动化……”
⇒【挑战】交给RPA吧
⇒【结果】成功实现日常任务自动化
⇒【挑战】
，它需要维护机器人执行环境，经常会导致处理延迟，但似乎对于日常任务（Excel 工作等）非常有用。
NoOps 不仅仅是配置基础设施。

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

NoOps是一种可扩展的架构，无法应用于正在运行的系统。

概括

文章已经变得相当长了。
这是一次非常丰富的活动。
接下来的课程我也参加了，都很有趣，充满了我不知道的东西。
“如何将本地数据库迁移到Azure SQL数据库？〜Benesse Shinkenzemi的案例研究〜”
“100年寿命时代的PDCA〜可用于职业和工作方式的PDCA的新旧使用方法改革 ~”
“面向 AWS 工程师的 Azure 无服务器”

第一天结束时举办了一场豪华派对！
我们一边吃着很多食物和糖果，一边享受着热闹的聚会气氛。
DJ 很认真，我以为这真的是俱乐部音乐。

顺便说一句，本田圭佑也作为嘉宾来了。
我最初是在 Twitter 上关注你的，但看到实物后我有点感动。
这不是“纯一戴维森”。这是真的。

只有我很高兴参加的会议。
希望明年我们的后辈们能再来尝试一下。