因火线沙龙第23期—云原生&DevSecOps专场的举办，沙龙群里各位大佬提前对议题进行了一番讨论。
运维还有未来吗？来看看群友怎么说吧！

Q1：怎么看待中台和多云管理？

A1：我认为这两个都是伪问题，没有研究价值，类似IT行业的气功治疗法。多云管理是资源纳管平台，实现基础设施资源统一管理和调度。云计算解决的是分布式网格计算问题，也就是算力问题。也就等同于利用CPU、内存、存储、网络等基础设施资源实现分布式计算、网格计算能力，通过提供标准化的基础设施资源计算服务（IaaS服务），支撑不同企业的大数据量计算和存储等需求。

B2：可以去用代码管理各种云的资源设备~ 移植、复制、升级，都会容易些_{上面两个可能还不够用，还需要多个环节去帮助完美实现，讲真一个企业用多个云，很多场景是必须的，有价值的}

A1：这种云计算的认知，还是把云当做特大号idc，只是存储计算网络三大件的资源池。实际上，云计算远远不只是一个资源池。云计算的定义可以有多个角度，我们先谈开发者角度：云计算是通过API把Infra和底层模块抽象为服务，用以提升开发运营效率的平台。

C3：“云计算” 这个概念或者符号本来就是用来简化复杂的事实场景的，就像人要取名字一样啊，这些分享和文章只要是合理的去解释某一个部分的场景，就是有一定价值的，可能你不喜欢，那你应该分享你的“观点”。

Q2：运维是不是要集体下岗了

A1：我的文章，共大家打靶子https://mp.weixin.qq.com/s/VkTUMax8dNMWygwaz9UPMg

D4：看这标题就不用看了，还定位运维在传统岗位上。现在网工都在开发自动化产品，早不是过去那个时代了。

C3：这篇的新意在哪里？我要的是新“观点”@马驰

A1：没啥新意，就是把我公司的做法总结一下，我们已经干掉了运维，连带dba和专职测试都被干了，只有网工和安全还在，其余都是dev。

E5：请教一下，没有运维的话，发布平台谁来负责啊？采购的第三方发布工具吗？还是让每个研发都去学ops，做CI/CD？

F6：第一次听说不需要运维的，是不是要把运维的工资给开发，让开发去运维呀

A1：对，devops

G7：那么，devops岗位算开发还是运维嘞

A1：根本就不应该有这个岗位，有这个岗位的公司，都是被伪专家忽悠了

H8： https://www.zhipin.com/job_detail/?query=devops&city=100010000&industry=&position= 看一下被忽悠的公司？

A6：什么都让开发干就行了，运维测试前端移动端，让后端一个人做就行了，后端无所不能

I9：这个思路不是干掉了运维，而是直接买了别人的运维相关的服务吧

J10：devops不是开发和运维的桥梁吗，怎么成把运维干下岗了..

A1：是的。all in cloud

A5：说明还是小公司，买服务就够了，不需要专业的效能团队来解决复杂问题

I9：我不太确定您公司的服务量级哈，这个两个选择就从简单的成本上面感觉就是不对等的

J10：就算有自动化服务，也需要人去干预吧

A1：一千个微服务，研发团队四千人，不算大，也不算小

A6：公司到了一定规模不都是自研嘛？只有小公司才是考现成的sdk

I9：这四千人里面没有人来做自己的devops相关的平台建设吗？还是直接走云的那一套流程的？如果直接用的话，在落地适配的时候没有什么不适应的地方吗？咱们这毕竟是安全沙龙哈，那devops这些需要和安全挂钩，卡点的部分应该怎么做呢？

A1：有个internal developer platform团队，规模还不小，但是他们只是把云和其他saas厂家的工具粘合起来。他们不是运维，不对sla负责。我也在探索。

K11：我看大家对干掉ops争议挺大的，其实您有机会可以来火线分享一下最佳实践，把具体怎么做摆出来也会比较有说服力，可能是个很有价值的探讨。

A1：其实没什么争议。除了运维总监们，大家都觉得运维团队要被干掉

H8：这个不错如何干掉运维那也是最高效的方式？教教我们

K11：这个群里运维不多，很多还是开发的，理论上并不对运维被干掉有多大的抵触，只是没有看到你们的最佳实践所以有异议。

L12：所谓的all in cloud，无非就是把运维的活丢给云平台去做了。并不是不需要运维。实际业务场景，公有云只是一种形式，规模更大的公司一定是混合云，所谓的干掉运维这是噱头。基础平台需要研发和运维。

M13：运维有很多日常工作，很繁琐的，比如开放安全组，加白名单等等这些小活儿

A1：所以安全团队现在就搞个爬虫，在公司每个repo里巡查，看到老版本的镜像，就提交个升级版本的pr看得出来，你没正经用过云，顶多在云上开了一百台虚拟机

L12：devops工具和云计算解决了很多重复性的工作，提高了效率。大公司本身已经有很多AIOps的实践了。大一点规模的公司，业务的日常扩容，容量规划都已经自动化了。说干掉运维是幼稚。

N14：一个律师因为会蛋炒饭，然后把厨师炒了，然后在别人做律师工作的时候去掌个勺

B2：今天我还在写文章，feature flags是如何让DevOps更偏重Dev的？我也特别关心这个话题 devsecops~ 我之前搞过devops，mlops，唯独对devsecops没经验，尤其是想关注我们的产品是否在devsecops里会有一些应用场景

A1：现在什么都shift left，但是安全真的移不动，没人愿意做安全工作。我们的安全工作，都是依靠安全团队邮件驱动。比如最简单的容器镜像打补丁，真的很烦。所以安全团队现在就搞个爬虫，在公司每个repo里巡查，看到老版本的镜像，就提交个升级版本的pr。

Q3：dev 和ops同学怎么看待安全？

O15：https://github.com/cncf/tag-security/blob/main/security-whitepaper/cloud-native-security-whitepaper-simplified-chinese.md 搭车推荐，参与翻译了云原生安全白皮书中文版

A1：好多地方要求太高了，“为了让客户端和服务器通过加密技术双向验证身份，所有的工作负载的通信都必须进行相互/双向认证。”， mtls带来的好处抵不上实施成本。

A1：内容质量很高，但是明显是安全从业者写给安全从业者的，没有考虑到其他团队对可实施性和成本的需求。

C3：系统被渗透之后，mtls就有价值了。tag-security 本来就是安全的分支，安全领域需要专业人士，这个文章很值得实践。

H8：我们最近也接入authing了，刚提到authing怎么解决ram安全问题的？

B2：我们也用上authing了，安全、省心

Q4：现在一切都是IaC化，大家有关注IaC的安全性的吗？

H8：国外像Synk checkmark 等很多产品都开始支持IaC安全这块，因为现在资源、网络甚至一些SaaS服务都可以被编排，IaC出现问题那可能有非常严重的后果。

A1：snyk吧，iac测试也不好做

H8：国内用IaC的好像不多，不太流行唉～

P16：IaC有不少开源工具，用起来还挺方便的

更多精彩请关注火线沙龙的举办！！下期更精彩！！