即将登陆您身边的网络。由另一种API经济呈现。
最近，DevOps社区开始更加关注文化。这可能是因为，如果不推动文化转变，营造更加开放、协作的跨IT环境，DevOps的诸多优势就无法得到充分发挥。封闭的“按需知悉”式信息共享会形成一个个孤岛，如同防御塔一般，将构成我们所熟知的“IT”的各个运维领域所特有的经验知识封闭其中。
但打破这些壁垒可能会带来痛苦和尴尬，而且极其困难。我们或许会拿几乎每位IT从业者“不善社交”的特点开玩笑，也会调侃那些刻板形象，但现实是，与大多数传说和童话一样，这些典型形象源于真实的行为和特征，而这些行为和特征至今仍是许多业内人士的写照。
我的迈尔斯-布里格斯类型是 INTJ，每次测试都是如此。没错，就是“建筑师”。在 Insights 性格类型中，我属于改革型观察者。其实，这不过是一种高度理想化的荣格心理测试，号称比迈尔斯-布里格斯测试更准确。不管怎么说，我基本算是个内向的人。如今，研究人员估计，近50%的人口都是内向者。想必您也不会意外地发现，其中许多人和我一样进入了IT行业，而那些令我们难以理解的外向型同伴则纷纷投身市场营销和管理岗位。
内向者不太喜欢“社交”，这是现在年轻人对与人互动的说法。真的，问题不在于你，而在于我们。我们处理信息和数据的方式与外向者不同，过多的主动互动会让我们不堪重负。我们也能社交，只是会筋疲力尽。我们更喜欢通过文字交流，也希望在回复前有时间思考。因此，我们其实很适应数字时代，因为很多交流正是以这种方式进行的：保持距离，通过文字沟通。如果你只在数字世界中认识我们，甚至可能会误以为我们是外向者。
如果考虑一下采用DevOps所需文化转变的前提，就会立刻发现其中存在冲突。分享和沟通都是DevOps的关键组成部分，这意味着要让一群内向者不仅与人互动，还要做到有效互动。因此，找到一种“不与人打交道也能与人互动”的方式，就像找到彩虹尽头的那罐金子一样难得。
事实证明，ChatOps或许正是那罐金子。
ChatOps：无人也能协作
那么，什么是ChatOps？Jason Hand是ChatOps领域的资深专家之一，他给出了一个简洁的定义：“可以把ChatOps理解为一条共享命令行。”
当然，ChatOps的内涵远不止于此，但从最基本的层面来看，这个定义是一个很好的起点。
诸如HipChat和Slack之类的工具并非像传统即时消息系统那样专为一对一沟通而设计。虽然也可以用它们进行一对一沟通，但这些现代通信平台的真正优势在于营造开放的沟通环境，让组织内所有感兴趣的人都能即时获取共享的信息和最新动态。我们鼓励潜水浏览，因为重要的是信息随时可用且易于获取，而不是持续不断地交谈。
频道（如#IRC）可用于控制有效信息与噪声的比例，并且通常能提供清晰的审计跟踪记录，说明谁在何时执行了什么操作。这些工具不只是聊天客户端，因此能够实现这一点。它们是平台，可通过API扩展功能，不仅能与人员进行双向通信，还能与系统进行双向通信。这意味着我可以添加一个#alerts频道，将基础设施组件发出的警报汇集到其中。
您可以相对轻松地为Slack构建一个“应用”，通过其API查询并返回信息。这些信息可能来自交换机、负载均衡器，也可能是当地天气。无论是什么，都可以在这些工具中调用命令，自动执行任务。还可以共享调用过程和结果，让所有需要了解或可能从中受益的人都能看到。系统会根据执行的操作记录任务并留下轨迹，便于其他人了解当前情况。例如，监控系统的状态更新、服务台的新工单，或服务器刚刚宕机、已不可用的通知。几乎任何能通过API传递的信息都可以与他人共享，而无需实际与人沟通。
这一过程为指导、培训和打破隐性知识壁垒创造了丰富的机会，让包括开发在内的其他IT领域也能从中受益。这是一种大规模的知识共享方式，无需把许多人聚集在同一个房间，也无需专门为满怀热情的新工程师开展培训。它也是少数能够推动必要文化转型的工具之一，有助于在“网络”领域成功采用DevOps方法。
而且，我们必须采用它。如果仍有顾虑，不妨思考一下Atlassian和xMatters在其《2017年DevOps成熟度调查》中提出的这个问题：
“既然有这么多组织都在监控基础设施、应用和服务，为什么仍有50%的受访者表示，代码发布后生产环境中出现了问题？ ”
作者根据数据提出了自己的假设，但我另有一种假设，主要基于合成谬误。它提醒我们，发布用于部署的应用与生产环境中运行的应用并不相同。应用服务的加入以及与网络的交互改变了应用的构成。除非在与生产环境完全一致的副本中进行验证，否则此前对该应用的验证将不再完全适用。
更糟的是，近1/3的公司直到客户报告服务中断后才发现这些问题。这可能与开发团队和IT团队之间的信息共享方式有关。29%的公司表示，团队之间仅在收到明确请求时共享信息。只有16.8%的公司会向所有人开放技术信息、目标、计划和结果。
如果缺少应用在生产环境中的特有行为信息，通常很难判断问题是什么，更不用说找到问题根源了。“在我的机器上可以运行”这句自我辩解式的口头禅，源于开发人员无法复现异常行为时的挫败感，而这种异常行为往往是由于缺少环境信息造成的。
即使我们并不急于开始自动化所有网络事务，ChatOps也是打通IT与开发团队沟通渠道的有效方式，有助于更深入地了解问题，从而缩短平均解决时间（MTTR）。它可以更全面地呈现“网络中”的情况，同时不会打扰工程师或对其进行微观管理。它让内向的员工无需面对面社交也能与人交流，从而鼓励他们更频繁、更全面地分享信息，甚至可能更加积极主动。
如果您刚开始接触ChatOps，我强烈建议阅读Jason Hand的电子书《ChatOps for Dummies》。虽然需要提供电子邮件地址，但很值得一读。
请继续关注。今后这里一定会分享更多有关ChatOps的内容。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。