共计 2759 个字符，预计需要花费 7 分钟才能阅读完成。
运维还有将来吗？来看看群友怎么说？
01
如何对待中台和多云治理？
@A1：我认为这两个都是伪问题，没有钻研价值，相似 IT 行业的气功治疗法。多云治理是资源纳管平台，实现基础设施资源对立治理和调度。云计算解决的是分布式网格计算问题，也就是算力问题。也就等同于利用 CPU、内存、存储、网络等基础设施资源实现分布式计算、网格计算能力，通过提供标准化的基础设施资源计算服务（IaaS 服务），撑持不同企业的大数据量计算和存储等需要。
@B2：能够去用代码治理各种云的资源设施~ 移植、复制、降级，都会容易些~ 下面两个可能还不够用，还须要多个环节去帮忙完满实现，讲真一个企业用多个云，很多场景是必须的，有价值的~
@A1：这种云计算的认知，还是把云当做特大号 idc，只是存储计算网络三大件的资源池。实际上，云计算远远不只是一个资源池。云计算的定义能够有多个角度，咱们先谈开发者角度：云计算是通过 API 把 Infra 和底层模块形象为服务，用以晋升开发经营效率的平台。
@C3：“云计算”这个概念或者符号原本就是用来简化简单的事实场景的，就像人要取名字一样啊，这些分享和文章只有是正当的去解释某一个局部的场景，就是有肯定价值的，可能你不喜爱，那你应该分享你的“观点”。
02
运维是不是要个体下岗了
@A1：我的文章，共大家打靶子
https://mp.weixin.qq.com/s/Vk…
@D4：看这题目就不必看了，还定位运维在传统岗位上。当初网工都在开发自动化产品，早不是过来那个时代了。
@C3：这篇的新意在哪里？我要的是新“观点”
@A1：没啥新意，就是把我公司的做法总结一下，咱们曾经干掉了运维，连带 dba 和专职测试都被干了，只有网工和平安还在，其余都是 dev。
@E5：求教一下，没有运维的话，公布平台谁来负责啊？洽购的第三方公布工具吗？还是让每个研发都去学 ops，做 CI/CD？
@F6：第一次据说不须要运维的，是不是要把运维的工资给开发，让开发去运维呀
@A1：对，devops
@G7：那么，devops 岗位算开发还是运维嘞
A1：基本就不应该有这个岗位，有这个岗位的公司，都是被伪专家忽悠了
@H8：https://www.zhipin.com/job_de… 看一下被忽悠的公司？
@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。
03
dev 和 ops 同学怎么对待平安？
@O15：
https://github.com/cncf/tag-s… 搭车举荐，参加翻译了云原生平安白皮书中文版
@A1：好多中央要求太高了，“为了让客户端和服务器通过加密技术双向验证身份，所有的工作负载的通信都必须进行互相 / 双向认证。”，mtls 带来的益处抵不上施行老本。
@A1：内容品质很高，然而显著是平安从业者写给平安从业者的，没有思考到其余团队对可施行性和老本的需要。
@C3：零碎被浸透之后，mtls 就有价值了。tag-security 原本就是平安的分支，平安畛域须要专业人士，这个文章很值得实际。
@H8：咱们最近也接入 authing 了，刚提到 authing 怎么解决 ram 平安问题的？
@B2：咱们也用上 authing 了，平安、省心
04
当初都是 IaC 化
大家有关注 IaC 的安全性吗？
@Q4：当初一切都是 IaC 化，大家有关注 IaC 的安全性的吗？
@H8：国外像 Synk checkmark 等很多产品都开始反对 IaC 平安这块，因为当初资源、网络甚至一些 SaaS 服务都能够被编排，IaC 呈现问题那可能有十分重大的结果。
@A1：snyk 吧，iac 测试也不好做
@H8：国内用 IaC 的如同不多，不太风行唉～
@P16：IaC 有不少开源工具，用起来还挺不便的