您好邵总,请您先做个自我介绍吧,聊聊您的履历和现状,让大家更好的认识您,了解您的背景也有助于读者理解后面的采访内容

我是来自又拍云的邵海杨,从1998年开始使用Linux至今快25年了,资深(老鸟)Linux系统运维/架构师,DevOps八荣八耻倡导者,业余撰稿人;精通(心虚)系统优化及网络服务管理,Linux系统定制,CDN加速和安全防御; 擅长互联网高性能网络及架构设计、虚拟化KVM及OpenStack云平台, K8S容器云和Ceph分布式存储等新技术;喜欢交流分享,活跃于社区,一直积极投身于开源活动的组织和传播。

运维领域,每个公司都会制定自己的运维准则或者操作规范,能否分享一下贵司的经验,给我们一些参考?

又拍云是一家提供云存储,云分发,云处理服务的公司,也是国内首创可编程CDN 服务的专业云服务提供商,特点就是7x24全年不间断服务,所以云运维也有一些律条或原则,比如:

先保障稳定,然后再优化

过度设计或过早优化很可能会带来更多的故障停机时间,要先集中精力提高系统的可扩展性和高可用性。坚持 “先完成,再完善,后完美”,项目也是“先能用,再好用,后用好”的实施策略。

提供可靠的测试依据和时间验证

引入新技术到架构之前,要确保新技术的稳定性和足够时间久的考验,更要有运维工程化中开发出来的工具链的完整。一旦线上返工或变更造成的措手不及可能已经是故障的导火索。

使用可控的自动化手段提升效率

自动部署、自动编排、自动巡检、自动升级等自动化手段越来越多应用于云运维。这是适应云计算时代的趋势,但能力越强,责任越大,要谨慎自动化的雪崩和惊群效应,做好灰度/蓝绿部署和各种测试。

保持简单,监控一切

保持简单,别把事搞得太复杂。除了常见的异常问题报警外,面向业务指标,市场指标和销售数据,成本等都可以用来做趋势分析信息。定期的轮询查看各个趋势数据的峰值峰谷有助于见微知著。

面向预算的运维

运维团队通常是最大的花费者,因为预算不足,没有钱的运维是很难兼顾到日益增长的公司业务规模,除非公司业务已经停滞或不再有爆炸式的增长,面对这样的挑战,运维要学会降本增益,开源节流,利用新技术实现能效比的提升。

面向场景的智能运维

各种各样的负载场景,从高并发处理到视频转码,从高性能并行计算到海量的网络请求。这些不同的负载场景,对网络带宽,各种处理和IO的要求也各不相同。智能运维就是需要深入理解业务,合理配置资源和架构来满足不同业务场景的需求。

持续集成和发布系统

持续发布包括灰度发布、测试发布、滚动发布、回滚发布等多种场景,并且确保每种场景都应该是可以可控的。

确保任何人都可以被替换

铁打的营盘流水的兵,人挪活是常态,做好员工的共享文档管理和知识传递和分享,理论上所有人都可以被替换,任何人也不应该成为公司的天花板。

虽说成长是自己的事情,但如果有合适的场域、合适的项目机会、合适的团队、合适的机制,会让工程师的成长更快,团队更有战斗力,您能否系统的谈一下是如何促成运维同学的成长的?

公司一直是积极鼓励员工的技能自我提高和促进成长:

  • 每月开放日:公司内技术委员会会定期举办讲座,分享前沿研究中的一些收获,要求有主题,有重点,有应用场景,最好有实例。

  • 每周分享会:鼓励所有开发者定期分享新的技术,谈论他们面对的问题,或者任何别的他们正思考的东西,分享的内容会形成文档和视频存档,并根据评分给予奖金和积分激励。

  • 公司悬赏项目:无论是公司还是员工自身都可以发起项目,技术委员会评审通过后,自行组队完成,根据产出文档,数据对比,技术分享后获取相应的项目奖金。申请专利还有相应的专利奖金。

  • 培养个人影响力:鼓励员工通过发表文章或演讲的形式,走出去做工程经验分享、工作心得的梳理,提高个人的影响力,并根据受众的反馈给予稿费和讲师费激励。

  • 订阅报刊,杂志等纸质书籍,了解最新动态。以部门为单位,配置一定的购书津贴。

又拍云运维团队内的培养包括:

  • 化“天花板为托板”:把自己放在一个培养新人的管理角色,不让自己成公司瓶颈和员工的天花板,鼓励新人们去尝新和处理故障,增加自身的技能和实战经验;信任,互助,激励,他们会持续不断创造惊喜。

  • 制作“自动化工具”:利用自己的经验抽象业务成程序模型,制作或培训自动化脚本的编写,提高团队的工作效率,让员工节省精力和时间去学*其它新知识;

  • 承担“高精专”项目:提前准备最新知识的研究和可行性分析,整理成文档作公开培训,再交给团队去深入研究和实施,转化成生产力,积累一线经验再反馈完善文档,良性循环;

  • 积极提倡“知识分享”:各种案例和“坑”都会整理成wiki文档,通过文档共享,定期分享讲座,鼓励员工撰写高质量的,可读性很强的文档,开口培训,增加感染力和自信心;

  • 鼓励“参与开源交流”:公司鼓励员工走出去参与技术交流大会,闭门造车耗时耗力,不如专业的人点拨。也会有购书经费,团建活动经费,茶歇文化;

运维工程师其中一个典型的职业路径是做管理者,但管理者和资深运维要解决的问题截然不同,对于那些刚刚步入管理岗的资深运维,是否可以分享一些您的经验?

对于刚步入管理岗的运维来说,我的建议是及时梳理遗留的技术债和人才技能的盘点和培养,先打好基础,后面才能有更大的空间进步,具体可以参考我的《DevOps的八荣八耻》的分享。

一、 以可配置为荣,以硬编码为耻

二、 以互备为荣,以单点为耻

三、 以随时重启为荣,以不能迁移为耻

四、 以整体交付为荣,以部分交付为耻

五、 以无状态为荣,以有状态为耻

六、以标准化为荣,以特殊化为耻

七、以自动化工具为荣,以手动和人肉为耻

八、以无人值守为荣,以人工介入为耻人

才上技能树的盘点,主要是配合人事做好人才九宫格的划分(如果是开发或运维,把左侧的绩效换成潜力,绩效针对销售而言),考查的是管理者对员工的全方面的辨析能力,知人善用。

再结合公司的OKR目标管理来激励员工,它的优点在于聚集目标的同时,还能:

  • 激励个人自驱力,鼓励员工创新和反思;

  • 考查的是相对结果,鼓励有难度的挑战和突破;

  • 考核的协同配合能力,鼓励员工去全方位的协调推进;

Kubernetes火了好一段时间了,很多公司也在大规模应用了,但显然,每个技术都不是银弹,无法解决所有场景的问题,这几年观察下来,您觉得哪些公司不适合上Kubernetes?能否给一个这类公司的画像,并说明理由?

虽然Kubernetes代表着目前为止的devops的最佳工程应用实践(真香),但也不是所有场合都能应用,如又拍云的CDN边缘服务器,数据中心的日志分析平台,Ceph分布式存储就以物理机为主。所以,我建议找一些合适的场景先试用起来,如:

  • 机器资源错峰空闲浪费严重的;

  • CPU,磁盘和网络IO都不密集的;

  • 不需要持久化存储的或抢占资源的;

  • 软件架构已经做了微服务改造的;

  • 业务处理程序有周期性、可弹性扩容的;

运维和研发是最亲密的伙伴,贵司是如何做工作边界划分的?另外关于如何让这两个角色保持亲密合作,是否可以分享一些经验?

  • 运维工程师 = 冲锋陷阵的将军

  • 软件工程师 = 坐阵帐中的军师

理论上,优秀的软件工程师是可以把部分(甚至全部)运维工程师的工作做掉,比如说业务软件性能的监控,如果程序员在程序中插入很多的钩子或探针,就可以统计出数据来,不需要运维劳心劳力的监控;比如说程序员在设计程序的时候,考虑到了分库分表,考虑到了大并发和分布式的设计,那运维就可以水平扩展机器就行;如果软件没有那么多bug,还有很多如果......但是,现实是残酷的,这种高水平的程序员太少了,尤其在中国,大家都忙于实现业务功能,连个文档甚至注释都不愿意写,更别提能够考虑这么周全了;同理,运维接触的很多是开源很优秀很成熟的软件,从中是可以借鉴知晓优秀软件是怎么设计的,比如优秀的程序,日志信息会非常详尽,我们可以通过标准的syslog或者日志去监控它,所以,资深的运维会:

  • 积极参与事前的规划,配合开发做演练,自动化部署,协助架构改进

  • 合理提需求,要资源,最好是有预算,做到防患于未燃

  • 线上监控,故障复盘,反馈给整个团队,倒逼上下协调做改进

当然,要达到上述能力的运维管理,肯定需要潜心研究,承上启下,协调团队,任劳任怨的修行多年,到那个时候,运维就不再是对事情的结果负责,而是转变角色,主导和协调整个过程。当然,这里指的能力不仅仅是技能,还包括对业务的理解能力,站在公司管理层面对整个项目和资源的分配和把握。因此,运维工程师其实是现实中的软件工程师的互补,因为大家的能力侧重点不同,所以大家更要团结一体,要能够打胜仗,离开谁都是不行的,这是一个共同修炼进步的过程。

最后,我的个人观点:架构师它可能不是一个人的角色,而是一个团队的统称,它可以:

  • 不必冲锋陷阵,就可以纵观全局,运筹帷幄,调度所有的资源(运维架构师的功能)

  • 可以带领和团结团队,高屋筑瓴,因时制宜的实现解决方案(软件架构师的功能)

  • 可以把握公司业务方向和深度,洽谈合作,控制成本(业务架构师的功能)

运维需要和其他多个部门沟通协作,鉴于各个团队目标关注点未必一致,合作起来可能未必有那么顺畅,针对这个问题您是用什么招来让这个过程更加顺畅的?

其实沟通不顺畅的原因大部分在于对后果的不可预见性,你说冗余他说预算,你说架构他说工期,各有立场又各有苦衷,但就是没人对结果负责。我在工作中发现,当故障发生时,各部门的配合是空前团结,战斗力也是最强的,所以,沟通协作的关键在于: 既要团队协作,也要责任分明

  • 事前部门沟通时,确定好项目预期,成本,影响要素,故障后果及责任方;

  • 事后故障复盘时,根据故障原因,有理有据地“甩锅”,同时要引以为戒,亡羊补牢;

比如说提供在线10W并发的能力,需要冗余带宽冗余服务器数量x2,因为预算不足减半所导致的后果及责任人;再比如软件设计不好,通过性能监控,发现指标异常的后果及责任人;当然,报警处理不及时,人为操作故障也会算到运维亦无可厚非;故障文化就是要关注问题和关注事情本身,对事不对人。大家都在故障中成长,在复盘中变强。

您觉得运维工作最重要的几个目标是什么?您是怎么落地这些目标的?

运维自动化;

监控常态化;

日志可视化!

这个篇幅太多了,不展开讲,可以参考《云运维的启示和架构设计

工具选型这块,到底是自研,还是使用开源,还是使用商业产品,是如何抉择的?

又拍云通常不会重复造轮子,但一定会先用好轮子,或者把轮子改造得更加称手,选择自研往往具备了一定的开发能力,再加上某些必要原因,如:

  • 找不到符合要求的开源软件,如我们自研的云处理软件…

  • 开源软件有bug或者issue,社区短期内无法推进,但业务又急需,只能通过自研解决,如ats的内存泄露问题…

  • 开源软件的功能特点跟公司的业务不相符合,不得不改造软件,如nginx的防盗链模块,需要与客户对接定制…

  • 开源软件的设计目标过于高大上,通用性好但很臃肿,如果我们只要某个小功能点,就不需要牛刀了,如性能探针的埋点…

  • 有数据保护要求,或者有隐私的场合…

越来越多的公司在迁往公有云,云原生架构下,SRE团队的核心职能是否有些变化?应该如何凸显团队的价值呢?

公有云作为IaaS基座,容器云作为CaaS中间层,云原生作为SaaS应用层,整个云生态日新月异,SRE团队的核心职能会更加注重顶层系统性的容量规划,指标监控,高可用性和分布式的弹性设计,所以跨平台跨部门的职能互补、团队协作、持续精进、勇于承担包括:

  • 积极参与事前的规划,配合开发做演练,协助架构改进;

  • 合理提可用性需求,冗余资源,最好是有预算,做到防患于未燃;

  • 线上监控,故障分析,反馈给整个团队,倒逼上下协调做改进;

团队的价值就在于是否总是能够接受新事物,新的挑战,各施所长,不做井底之蛙,也不是温水煮青蛙,在创新或者颠覆来临的时候,也能保持不被时代脱钩。

对于运维工程师个体,SRE的转型路径是?应该注意些什么?

技术领域

  • 学会抽象业务模型,标准化组件,定制化脚本,自动化部署,提升整体效率;

  • 学会收集日志和日志分析并可视化,提升运维监控和预警报警的效率;

  • 掌握和熟悉一门或若干语言,能够帮助你成长,提升你的战斗力;

  • 勤做笔记,温故而知新,学思结合,要学会沉淀,举一反三;

  • 勇于面对新兴技术的挑战,打不过就学它;

非技术领域

  • 学*能力,要知识面广;

  • 沟通方面,了解客户的精确需求;

  • 技术风险、人工、进度等成本,权衡取舍;

  • 社区活动,积极分享,锻炼口才和交流能力;

  • 提升自己的影响力,学会与人同行,可以交到更多的朋友;

面对当下快速发展的基础技术,您对给刚入行和入行已久的运维人员,分别有什么职业规划的建议吗?

首先不是工作选择人,而是人选择工作,一个人若对某方面有了兴趣,真正用心学*了*10000个小时,其实做什么都是可以的。比如说我毕业那个时候,都是强调复合型人才,根本没有运维这个职业,我们不光自己攒(DIY)机器,自学Linux操作系统,还学*编程,折腾网络,自己动手写论坛聊天室等程序;Linux给我们带来的是每天都有创新的,好玩的,优秀的开源软件让我们保持激情去尽情的折腾和学*,当互联网兴起的机会来临时,做个运维总监其实也是顺理成章的事;其实,除此之外,我还转型做过售前,技术支持,跑过市场,经常做演讲培训,所以真正的高手是什么不会学什么,技多不压身,做个懂业务、会开发的运维工程师。

您觉得运维人员最重要的素养是什么?对新入行的运维人员有哪些寄语?

我认为最重要的能力是表达沟通能力,但不排除运维本身所需的技术储备、实践动手能力、编程能力和学*能力。考虑到运维大部分还是一个成本支出的岗位,如何把深奥隐晦的性能及瓶颈指标,用直观的图表展示来获取上层持续的投入是需要技巧的;然后面对你的同事,你的兄弟部门,也需要你的影响力去协调推进工作,如果能够做到这些,说明你已经具备了领导的才能,这样以后做什么事都会站在更高的水平,用全局观的格局去统筹规划整个项目的目标,人员,工期和资源的合理分配和把握。

又拍云邵海杨 - 25年Linux老兵,聊聊运维的“术”与“道”的更多相关文章

  1. SuperEdge 云边隧道新特性:从云端SSH运维边缘节点

    背景 在边缘集群的场景下边缘节点分布在不同的区域,且边缘节点和云端之间是单向网络,边缘节点可以访问云端节点,云端节点无法直接访问边缘节点,给边缘节点的运维带来很大不便,如果可以从云端SSH登录到边缘节 ...

  2. 优云软件助阵GOPS·2017全球运维大会北京站

    GOPS· 2017全球运维大会北京站于2017年7月28日-29日在北京隆重举办,汇聚国内一线运维专家和诸多运维同仁达800余名.作为长期致力于企业级高端运维市场软件开发和咨询服务的优云软件受邀参与 ...

  3. 博云 x 某农商行 | 银行信息化运维系统升级的最佳实践

    随着银行新一代信息化运维系统建设的推进,应用系统更新换代速度明显提升.数字化转型的发展对银行业务需求的敏捷性提出了越来越高的要求,促进敏捷开发和资源敏捷部署成为大势所趋. 背景 江苏某农村商业银行成立 ...

  4. 技术沙龙|京东云DevOps自动化运维技术实践

    自动化测试体系不完善.缺少自助式的持续交付平台.系统间耦合度高服务拆分难度大.成熟的DevOps工程师稀缺,缺少敏捷文化--这些都是DevOps 在落地过程中,或多或少会碰到的问题,DevOps发展任 ...

  5. 阿里云发布CloudOps白皮书,ECS自动化运维套件新升级

    12月10 日,2021云上架构与运维峰会上,阿里云发布业界首部<云上自动化运维白皮书>(简称CloudOps白皮书),并在其中提出了CloudOps成熟度模型.同时,阿里云还宣布了ECS ...

  6. 从好用到更好用 —— 2017 年又拍云 CDN 功能更新回顾

    又拍云一直致力于为客户带来更好的服务,在 2017 年又拍云 CDN 服务进行了数次重大更新,在功能上更加全面.完善,进一步提升了 CDN 的稳定性与安全性. 在过去一年里又拍云 CDN 服务共进行了 ...

  7. 关于又拍云免费cdn全网加速服务的长期评测(各种踩坑)

    原文转载自「刘悦的技术博客」 ( https://v3u.cn/a_id_128 ) 妇孺皆知,前端优化中最重要的优化手段之一就是cdn加速,所谓cdn加速就是采用更多的缓存服务器(CDN边缘节点), ...

  8. ajax异步上传到又拍云的实例教程

    作者:白狼 出处:www.manks.top/article/async_upload_to_upyun 本文版权归作者,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否 ...

  9. iOS UPYUN(又拍云)使用总结

    UPYUN,原来没用过,上个周用了一次,觉得蛮方便的,对于个人开发者,且没有服务器的,上传图片和文件,是个不二选择. 首先,先明白原理: 1.又拍云有一个上传空间,在这个空间里,有空间名称.密钥,其他 ...

  10. 使用plupload绕过服务器,批量上传图片到又拍云

    本文最初发布于我的个人博客:Jerry的乐园 综述 论坛或者贴吧经常会需要分享很多图片,上传图片比较差的做法是上传到中央服务器上,中央服务器再转发给静态图片服务器.而这篇文章讲介绍如何使用pluplo ...

随机推荐

  1. 中龙技术 | HSCSEC CRY + MISC WP

    CRYPTO[HSC-1th] Easy SignIn 5445705857464579517A4A48546A4A455231645457464243566B5579556C7053546C4A4E ...

  2. 生产实践:Redis与Mysql的数据强一致性方案

    公众号「架构成长指南」,专注于生产实践.云原生.分布式系统.大数据技术分享. 数据库和Redis如何保持强一致性,这篇文章告诉你 目的 Redis和Msql来保持数据同步,并且强一致,以此来提高对应接 ...

  3. Modbus 转PROFINET 网关 TS-180在级联通讯中的应用

    一.硬件连接 TS-180 具有冗余网口功能,用户可以通过级联方式连接来进行通讯,其他资料可参考说明书.将西门子 S7-300 PLC 通过网线与5台 TS-180 串联,用户可以选择下列两种连接方式 ...

  4. Java自定义ClassLoader实现插件类隔离加载 - 原理篇

    书接上回 在 Java自定义ClassLoader实现插件类隔离加载文章中,我们通过 自定义ClassLoader + 插件独立打包引入的方式,实现了同依赖不同版本的隔离加载 这次咱们来分析下具体实现 ...

  5. 创建一个循环写入数据有事务提交的oracle函数示例

    /*创建函数*/create or replace function fnc_testtempInfo(startDate IN varchar2, endDate in varchar2) retu ...

  6. macOS 苹果电脑双面打印单面打印PDF设置

    苹果的打印服务分为两个部分,一个是应用层另一个是系统层. 其中双面打印或单面打印统一在系统层面设置,下面我分别截图示意wps pdf和福昕pdf两款软件设置双面打印. 1.WPS PDF 在完成方式中 ...

  7. javaAPI操作hbase对表格的增删改查

    package org.example; import org.apache.hadoop.hbase.NamespaceDescriptor; import org.apache.hadoop.hb ...

  8. 神经网络优化篇:详解dropout 正则化(Dropout Regularization)

    dropout 正则化 除了\(L2\)正则化,还有一个非常实用的正则化方法--"Dropout(随机失活)". 假设在训练上图这样的神经网络,它存在过拟合,这就是dropout所 ...

  9. 万界星空科技服装行业mes解决方案

      服装行业MES特色 企业透过全球供应链网络掌握实时的订单进度信息来实现电子商务排除生产现场自动化"孤岛",建立起业务计划层到控制层的桥梁,JIT库存管理与看板管理.精益生产与敏 ...

  10. pytest框架学习-前置和后置setup和teardown

    前置和后置 (1)setup和teardown,方法级 写在类中 方法级,每个用例都会执行setup和teardown. 相当于setup_method和teardown_method (2)setu ...