中台和多云管理是伪问题?运维要集体下岗了吗?

运维还有未来吗?来看看群友怎么说?

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有不少开源工具,用起来还挺方便的

你可能感兴趣的:(运维)