devops

点击上方“ 方志朋 ”，选择“ 设为星标 ” 回复” 666 “获取新整理的面试文章 组织在采用DevOps后，每一步的决策都离不开数据。 因此，如果没有监控系统正常运行时间，网络负载和资源使用情况等关键指标，DevOps人员就无法在系统故障时，清楚地知道对哪部分优化。幸运的是，我们现在可以使用各种各样的监控工具来帮助软件系统收集和查看此数据。 确定监控什么以及如何进行监控，这很重要。在这篇文章中，我们将带你了解基础的监控知识，我们还将列举一些流行的监控工具供你参考。 在哪里实施监控 首先，你需要确定在系统中的哪个位置实施监控。根据监控的位置，你将能够观察不同类型的数据。以下是最常见的监控类型。 资源监控： 也称为服务器监控或基础结构监控，它通过收集有关服务器运行的数据来进行操作。资源监控工具报告RAM使用情况，CPU负载和剩余磁盘空间。这些有关硬件运行状况的信息（例如CPU温度等），也影响着服务正常运行。在基于云的环境中，虚拟服务器的聚合信息更为有用。 网络监控： 这将查看计算机网络进出的数据。你的监控工具可以捕获有关组件（如交换机，防火墙，服务器等）中的所有请求和响应。 应用程序性能监控： APM解决方案收集有关服务运行情况的数据。通过这些工具，我们可以对应用程序性能问题进行检测和诊断，以确保服务以预期的水平运行。 第三方组件监控：

随着移动互联网的发展，手机银行凭借低成本、操作简单、不受时间空间约束等优势， 正逐步替代传统的网银交易方式。越来越多的银行开始了“ 业务移动化 ”转型之路，“手机APP”已经成为企业价值传递和关系维护的关键纽带，客户争夺的主战场已转向移动端，事实上手机银行的用户比例早已超越了网银用户。 但是伴随着银行APP承载的业务需求日益增多、版本迭代速度不断加快，以“ 手工测试 ”为基础的测试体系，已很难满足业务对测试效率和质量的要求。 APP 测试急需完成从“纯人工”到“人机协同”的范式转换。 一、银行 APP 的质量挑战 银行类APP所承载的业务，都是围绕“钱”展开，比如转账、理财、支付等核心功能，都不开“钱”。而在实际研发过程中，在确定的发版时间约束下，版本实际开发完成后，往往留给测试团队的时间很短，加上使用人工测试，功能覆盖面难以保障，且人工测试效率低下，导致版本发布后问题频出。 Top 10 金融 APP 测试通过率仅 52%，无响应、白屏、显示异常现象频出，导致用户体验差。 总结来说，银行在APP测试中，主要面临两大挑战： （1）功能测试场景：脚本自动化难、脚本维护复用难、参数管理难 （2）兼容性测试场景：没有足够多的机型覆盖 1.1、功能测试场景 1.1.1、“手工”测试难以应对业务快速迭代的挑战 业务需求多，发版节奏快 银行业务转型到手机APP后，APP 成为企业“链接

本文首先会和大家分享当前整个应用生命周期的演变历程，然后讲解云计算模式下 DevOps 建设包含的过程、流程规范和标准，最后讲解云原生时代到来会带来哪些改变，以及标准化的建设会有哪些改变和突破。 应用的演变历程 企业数字化转型过程和云的迭代发展是相互作用的。在 2007 年之前主要用物理机来作为我们当前应用的载体。而在 2007 年，KVM 诞生，它能让底层操作系统和一些虚拟的网络设备做一些虚拟化的输出。2007 年 - 2010 年是虚拟化发展较好的周期，VMware 和 openstack 是当时的代表生态。到了 2013 年 Docker 开服，云计算迎来了蓬勃发展的周期。2014 年，企业的部分业务开始逐步迁移云上。2017 年后到今天为止，在云原生的模式下，开发人员或者整个 it 部门更聚焦在业务的发展上，所有我们不关心的部分可以全部由云来管理。云开发不必关心开发在哪里，云服务不关心调用到哪里，而云资源方面也不用关心运行到了哪里。这就是从基础设施上云到业务上云，再到当前的全栈云，这样的一条全企业数字化转型之路。 在物理机阶段，使用的是单体架构，这样的架构系统封闭、无法复用，且高度耦合，内部交互复杂。而在第二阶段，采用了面向服务的 SOA 架构，这种架构通常需要 ESB 进行系统集成，进行应用模块解耦，需要统一部署。但是这种架构通常需要较大规模的团队，且可能存在职责割裂

​BuildRun企业级低代码开发平台基于拖拽式的开发方式，提供丰富的服务组件来满足企业数字化应用的设计、构建、集成、部署和管理，赋能各团队来帮助他们构建全场景的数字化应用。 BuildRun 企业级低代码开发平台1.2 版本 正式发布 新增 可视化工作流 ，支持自定义工作流程（BPM特性），通过低代码的开发方式将工作流程自动化轻松融入系统，提高运营效率、改善资源利用。 接下来将以 制作一个请假审批流程 的操作为例，来展示工作流的使用，欢迎大家试用体验。 01 前置条件 在开始自定义工作流之前，需要先创建工作流发起和审批的相关页面，以及相关业务对象、选项集等数据源。（开发者和业务人员皆可操作） 步骤 ： 创建业务对象“请假”；添加属性“日期”、“请假原因” 创建“请假发起页面”，添加表单，设置字段“日期”和“请假理由” 创建“请假审批页面”，添加表单，设置字段“创建人名称”、“日期”和“请假理由” 设置应用菜单 相关操作指南可查看《 Buildrun低代码开发教程 》 BuildRun低代码开发教程第三节 | 数据模型设计和定义 BuildRun低代码开发教程第四节 | 应用的页面创建和菜单设置 02 创建工作流模板 工作流模板是流程自动化的基础，BuildRun的可视化工作流功能目前提供了多个常用节点和操作节点，保证了工作流模板基础规则设置。（开发者和业务人员皆可操作） 步骤 ：

一、算法最最基础 1、时间复杂度 2、空间复杂度 一般最先接触的就是时间复杂度和空间复杂度的学习了，这两个概念以及如何计算，是必须学的，也是必须最先学的，主要有最大复杂度、平均复杂度等，直接通过博客搜索学习即可。 二、基础数据结构 1、线性表 列表（必学） 链表（必学） 跳跃表（知道原理，应用，最后自己实现一遍） 并查集（建议结合刷题学习） 不用说，链表、列表必须，不过重点是链表。 2、栈与队列 栈（必学） 队列（必学） 优先队列、堆（必学） 多级反馈队列（原理与应用） 特别是优先队列，再刷题的时候，还是经常用到的，队列与栈，是最基本的数据结构，必学。 3、哈希表（必学） 碰撞解决方法：开放定址法、链地址法、再次哈希法、建立 公共溢出区（必学） 布隆过滤器（原理与应用） 4、树 二叉树：各种遍历（递归与非递归）（必学） 哈夫曼树与编码（原理与应用） AVL树（必学） B 树与 B+ 树（原理与应用） 前缀树（原理与应用） 红黑树（原理与应用） 线段树（原理与应用） 树相关是知识还是挺多的，建议看书，可以看《算法第四版》。 5、数组 树状数组 矩阵（必学） 三、各种常见算法 1、十大排序算法 简单排序：插入排序、选择排序、冒泡排序（必学） 分治排序：快速排序、归并排序（必学，快速排序还要关注中轴的选取方式） 分配排序：桶排序、基数排序 树状排序：堆排序（必学） 其他：计数排序（必学）

越来越多的科技公司正在从传统的企业销售思路转变为以开发者至上的思路来推广产品。因为开发者不喜欢这类销售方式，所以电话销售和演示将不起作用。 相反，平台需要采用类似于消费者可能采用手游或电商应用的方式。 但是，开发者也不太可能接受那些游戏和电商应用上的那些Facebook广告。 启动开发人员关系计划，可以推动开发者的使用并建立起更有效的关系，但是由于开发人员关系是一个崭新的角色，所需的技能和责任相比销售和工程等已经成熟的角色来说更加模糊。 本文概述了招聘开发者关系经理时应注意的事项。有关开发人员关系的概述，可以先了解一下什么是开发者关系。 因为开发者关系对于任何与开发者社区互动的人来说都是一个包罗万象的角色，所以在面试任何候选人之前，你应该列出这个角色的关键目标。一些开发者关系的角色侧重于社区参与和开发者宣传。 他们的主要目标是提高产品认知度，这要求他们在会议上发言，扩大自身影响力，并参与社交社区（如Twitter或Reddit）互动。 其他一些开发者关系的角色更专注于产品管理和开发者经验。他们的主要目标是平台的采用和使用，这要求他们通过迭代的方式完成用户引导、文档与公共的API/SDK。 无论扮演那种角色，开发者关系经理都需要清晰地沟通，并深入浅出地把深奥的技术主题表达出来，以便开发者轻松的理解。很多时候，开发者关系是公司线上线下的形象代言人。 | 1.

告警 晚七点刚好上地铁，握在手里的手机震动了好几下，根据震动这几下的手感已经判断出这是钉钉在告警了，十有八九就是线上的问题，通过Zabbix监控的一台线上服务器已经五分钟不可达，这应该不会是网络网络问题了，如果是网络问题，其他线上机器应该都会不可达。没背电脑，只能干着急，后来大概看了一下云平台是因为CPU过高导致的。过了大概半个小时，有自动恢复了。 其实这个问题隐隐约约出现好几次了，只是没去重视，今天一来到公司就开始打开xshell，啪啪啪几下登录上去之后，袖子一卷，准备好好排查一下，看看到底是何方妖怪让我的CPU飙升还机器都连不上去。 排查 呆呆的看着这个黑色的框框，没错，我呆呆的看着他看了一天了。因为我完全没有头绪，没有思路，从哪里下手？按照平时的套路，看日志，打开几个相关的日志，眼睛都瞄没了，也没找到什么有用的东西。网上搜索一下，看看有么有什么好的办法排查，打开Google，打开baidu，千篇一律，简直就是复制粘贴，基本上使用top找到CPU占用高的进程，然后看进程的日志。但是我现在已经不是第一现场了。回想起了以前面试的时候面试过经常会问当你的机器CPU突然很高时，你怎么办？头脑里也一次又一次的出现平时说要好好看看linux系统的书，没看，真后悔，等这次后我一定要把这方面的知识好好学习学习，系统的学习。可是等今晚回去睡一觉，明早一醒来，还是原样。 反思 日复一日，年复一年

今年元旦节，我写了第一篇有关管理的文章： #工程师如何从技术转型做管理# 这篇文章系统性地总结了「从技术往管理转型期间，会遇到的挑战和应对方法」，累计有7万左右的阅读，引起了挺多过来人的共鸣。 对于初级管理者来说，「能否顺利转型」是第一大挑战，因为它会决定你后续的发展路径。最终的结果无外乎这两类： 第1种，放弃转型，发现自己不适合做管理，最终回到技术岗位，走专家或者架构路线。 第2种，接受转型，认可管理者的价值，并且愿意投入热情和精力走好管理这条路。 针对第2种情况，每个人的成长速度似乎又完全不一样。我身边有挺多一线管理者，摸爬滚打了好几年，一直没法晋升到中高层管理。而有些发展快的，2-3年时间便能跨越一个层级。 到底是什么原因决定了这个差距？如果想在管理上做到快速成长，有没有可参考的建议呢？ 从技术经理到二线公司的总监，我经历了团队规模从几人到几十人的变化，用心体会过团队建设的方方面面。针对上面这个问题，我谈谈我个人的 2 点看法。 — *1* — 做成什么样，才算做好了？ 作为管理者，这是你必须要想清楚的第一个问题，也是最重要的一个问题。 为什么这么说呢？这个逻辑其实和技术晋升是一个道理，重点看两件事： 1，你能否在当前职级做出被认可的成绩 2，你的能力是否接近下个职级的要求 看似简单的问题，其实背后会体现了你对管理者的角色认知和思考深度。 做管理的，都知道要带着团队把事做好

在互联网快速发展的这些年，软件工程的协同方法也在同步升级：从传统的瀑布，到敏捷，再到微服务和中台化。但是先进的开发模式并非万能的解药，996几乎成为了程序员的标配，似乎有种效率不行、工时来凑的趋势。 前几天和同事聊天，谈到了一个特别有意思的现象：我们一起经历了两家创业公司，但是能明显感觉到新公司在研发效率和研发质量上都比前公司好太多，然而这两家公司的基础设施以及工程师水平差距并不大。 下面这些现象更是在创业公司屡见不鲜： 研发团队人很多，大家也很辛苦，但是仍然被业务吐槽迭代速度慢。 开发、测试、产品彼此不信任，害怕背锅，整天各种扯皮。 开发人员疲于应付新需求，同时线上故障频繁出现，一边做新feature一边改BUG，迭代节奏完全被打乱。 随着创业公司的快速发展，研发效率跟不上是最容易出现、也是最急需解决的问题。如何快速做出调整真的非常挑战组织能力和管理水平。 做好了，能为业务发展保障护航，让技术同学的投入更有价值；做不好，不仅会拖业务后腿，而且很有可能让团队氛围变糟，优秀人才流失，最终彻底击垮一个团队。 这篇文章，我将结合自己的经验和理解，分别从组织架构、流程制度、工程方法、团队文化4个角度聊聊：如何让研发团队的工作更加高效？ 01 组织架构 做到和技术架构同步升级 组织架构决定了协作方式。当一个组织变成一个「利益共同体」时，效率才能真正体现出来。否则组织之间只会相互推诿

前记： 体系就像是一顶帽子，是对DevOps运维的一个深度总结，写一下工作中的感悟，希望对你有所启迪。 DevOps体系是从原始运维一步步走过来的，原始运维好比是本，有了本进而想继续提升效率、减少出错、优化流程，就发展到了DevOps，AiOps....... 首先，运维的业务职能规范后形成章程、纲领，在互联网快速发展的特点下，形成了一套应对"快"和"变"的体系，并不停的迭代升级，工作这些年，体会到千象背后是有恒道的，运维工作一直围绕 高SLA 和 低成本 的业务目标运转着，只是工具在围绕着体系变来变去。从开发的角度理解， 运维体系就像是算法，实现算法的语言就像是工具，DevOps就是工具的升级 。 工具的本质其实是一个基础支撑，有了这个支撑，一系列目标的实现才更科学、高效，简单示意如下。 原始阶段，运维工程师与各部门无数的磨合、探索下，慢慢形成了最初的体系，其无形的规范着运维的工作和注意事项，工程师通过这个纲领开展日常工作并保障业务的健康发展，这个阶段可以说是 制度为王、制度规范 ，没有系统的运维平台，有的只是零散的一些大小工具，各种事物基本靠人工、靠制度、靠约束，虽是原始阶段，但也是运维最真实的样子，忙碌而又忙碌，效率总跟不上需求，制度总跟不上执行，与开发的协作总难同一频道，需要大量的运维人力。 再向后发展，为了提高效率的同时解决与开发间的沟通协作问题，提出了DevOps