运维工程师

安全 运维人员的权限很大，一定要保证账号/私钥的安全 使用加密工具存储，给ssh私钥加密码，基于本地存储；稳定安全是运维的最高责任。 责任心 遇到报警要第一时间进行处理，不用等着别人去处理；如无法处理，应该第一时间让同事协助帮忙， 细心 自己的任何一个操作都要谨慎，都有可能造成系统的损害、业务出问题等。敲命令一定细心、再三确认，再快的手速也就省下几秒钟，但是出了问题就是大事 推进及改善 如果代码有问题，造成系统的开销很大，比如负载、io等，应该第一时间和开发联系，优化代码。 进取心 运维知识广泛、要不断的学习。遇到问题，做好分析及记录，事后可以在部门内部进行分享和交流。 懂网络、懂系统、懂数据库、还要懂业务逻辑。 抗压能力 拥有良好的心态。 永远不要只有一个方案 解决问题不要只想一个方案，多想几个方案，多几手准备反正不会有坏处~ 沟通能力 描述问题： 你需要描述清楚在工作中遇到的问题，及时寻求帮助。 解释不能实现的功能： 当你向客户解释某个产品的功能时，哪些是可以展现出来，哪些是不能实现，那不能实现的功能有没有替代方案，都需要描述清楚。 来源： 51CTO 作者： 沈夣未央 链接： https://blog.51cto.com/13870640/2448453

AIOps 自从 Gartner 于2016年提出至今已有一段时间，虽然在顶级互联网及电信企业，已有较多落地，但至今仍无基于生产实践的理论体系及实施指南。 高效运维社区和云计算开源产业联盟（OSCAR联盟）牵头，和互联网大厂如 BATJ、360、华为、平安科技等的 AIOps 负责人联合编写了国内外首个《企业级 AIOps 实施建议》白皮书，以缩AIOps 实施路径。 一、整体介绍 AIOps，即 Artificial Intelligence for IT Operations，智能运维，将人工智能应用于运维领域，基于已有的运维数据（日志、监控信息、应用信息等），通过机器学习的方式来进一步解决自动化运维没办法解决的问题。 早期的运维工作大部分是由运维人员手工完成的，这被称为手工运维或人肉运维。这种落后的生产方式，在互联网业务快速扩张、人力成本高企的时代，难以维系。 这时，出现了自动化运维，用可被自动触发的、预定义规则的脚本，来执行常见的、重复性的运维工作，从而减少人力成本，提高运维效率。 自动化运维可以认为是一种基于行业领域知识和运维场景领域知识的专家系统。 但是，随着整个互联网业务急剧膨胀，以及服务类型的复杂多样，“基于人为指定规则”的专家系统逐渐变得力不从心。自动化运维的不足，日益凸显，这也为 AIOps 带来发展机遇。 AIOps 不依赖于人为指定规则

运维框架 目录 运维框架 1 1. 基础知识 5 1.1 系统原理 5 1.2 命令基础 6 1.3 网络基础 6 1.4 排错基础 6 1.5 优化基础 6 1.6 安全基础 6 1.7 原理基础 6 2. WEB 管理 7 2.1 Nginx 7 2.1.1 部署 7 2.1.2 优化 7 2.1.3 备份 7 2.1.4 恢复 7 2.2 Httpd 7 2.3 Tomcat 7 2.4 IIS 7 3. 数据库 7 3.1 MySQL 7 3.1.1 部署 7 3.1.2 优化 7 3.1.3 备份 7 3.1.4 恢复 7 3.2 Oracle 8 3.3 MongoDB 8 3.4 Redis 8 3.5 Memcached 8 4. 消息队列 8 4.1 ActiveMQ 8 4.2 RabbitMQ 8 4.2.1 部署环境 8 4.2.2 版本依赖 8 4.2.3 安装包下载地址 8 4.2.4 安装步骤 8 4.2.5 常用命令 9 5. 监控 11 5.1 Zabbix 11 5.2 Prometheus 11 5.3 Cacti 11 5.4 Nagios 11 6. CI/CD 12 6.1 Jenkins 12 7. 日志管理 12 7.1 ELK 12 8. 高可用 / 集群 12 8.1 Lvs 12 8.2 Keepalived 12 8.3

提高DevOps工程师软技能，可以了解一下笔者前一篇文章《DevOps工程师必备软技能》 《凤凰项目》是DevOps界神书，虽然内容表现形式是小说，但是依然是敏捷开发及DevOps领域的必读书籍。很多知名的咨询师都是通过此书开启了DevOps及敏捷之旅，书中故事均来源于运维的日常工作，正是体现了艺术源于生活、高于生活的本质。笔者间隔两年时间，阅读此书两次，希望可以讲书中了解到的一些经验分享给大家。 小说主人公比尔，临时接任了IT运维经理的职位，然而此时，公司已经经历了多轮裁员，生产线上故障不断。董事会指望凤凰项目重启拯救公司，然而面对的着层层困难，比尔开始不停的应付突发的线上故障，身心俱疲。为了生存及公司的正常运转，尝试出一套适合该公司的IT转型方案，整个转型过程就像我们从传统开发模式转型DevOps的开发模式一样，踩过很多坑，总结出很多道理，小说的内容我不过多叙述，了解精彩的故事可以直接去购买图书，下面会给大家总结一下书中的一些重要的经验。 1. IT的四种工作形态 在故事中，主人公比尔在接替IT部经理后，通过一系列的故障处理与人际交流的过程中，得出了这个结论。IT的工作无非就是如下四种类型： IT部门内部项目 业务组项目 变更工作 救火工作 其实上述四种工作类型与我们目前运维部门的状态基本一致，我们需要开发自己的运维与监控平台，要参与到业务部门的开发测试中

3 月，跳不动了？>>> 《凤凰项目》是 DevOps界神书，虽然内容表现形式是小说，但是依然是敏捷开发及DevOps领域的必读书籍。很多知名的咨询师都是通过此书开启了DevOps及敏捷之旅，书中故事均来源于运维的日常工作，正是体现了艺术源于生活、高于生活的本质。笔者间隔两年时间，阅读此书两次，希望可以讲书中了解到的一些经验分享给大家。 小说主人公比尔，临时接任了 IT运维经理的职位，然而此时，公司已经经历了多轮裁员，生产线上故障不断。董事会指望凤凰项目重启拯救公司，然而面对的着层层困难，比尔开始不停的应付突发的线上故障，身心俱疲。为了生存及公司的正常运转，尝试出一套适合该公司的IT转型方案，整个转型过程就像我们从传统开发模式转型DevOps的开发模式一样，踩过很多坑，总结出很多道理，小说的内容我不过多叙述，了解精彩的故事可以直接去购买图书，下面会给大家总结一下书中的一些重要的经验。 1. IT的四种工作形态 在故事中，主人公比尔在接替 IT部经理后，通过一系列的故障处理与人际交流的过程中，得出了这个结论。IT的工作无非就是如下四种类型： IT部门内部项目 业务组项目 变更工作 救火工作 其实上述四种工作类型与我们目前运维部门的状态基本一致，我们需要开发自己的运维与监控平台，要参与到业务部门的开发测试中，要进行所有基础设施及应用版本的变更与升级。而这些都是属于正常的工作

某厂面试归来，发现自己落伍了！>>> 从 2019 年初开始，阿里巴巴云原生应用平台团队开始逐步在整个阿里经济体内，基于标准应用定义与交付模型进行应用管理产品与项目统一架构升级的技术工作。 事实上，早在 2018 年末，当 Kubernetes 项目正式成为阿里巴巴的应用基础设施底盘之后，阿里内部以及阿里云产品线在应用管理领域的碎片化问题就开始日渐凸显出来。 尤其是在云原生生态日新月异的今天，阿里巴巴与阿里云的应用管理产品架构（包括阿里内部 PaaS 和云上 PaaS 产品），如何以最佳姿态拥抱云原生生态、如何以最高效的技术手段借助生态日新月异的能力构建出更强大的 PaaS 服务，而不是重复造轮子甚至和生态“背道而驰”，很快就成为了阿里团队亟待解决的重要技术难题。 但棘手的是，这个问题并不是简单把 PaaS 迁移或者集成到 Kubernetes 上来就能够解决的：PaaS 与 Kubernetes 之间，从来就没有存在这样一条清晰的分界线，可是 Kubernetes 本身又并不是面向最终用户设计的。 如何既让全公司的研发和运维充分享受云原生技术体系革新带来的专注力与生产力提升，又能够让现有 PaaS 体系无缝迁移、接入到 Kubernetes 大底盘当中，还要让新的 PaaS 体系把 Kubernetes 技术与生态的能力和价值最大程度的发挥出来，而不是互相“屏蔽”甚至“打架”

摘要：信息化高度发展的今天，企业（组织）的信息化程度已是今非昔比，IT基础设施规模空前庞大，IT资产安全已不容忽视，认识并选择合适的堡垒机，对企业（组织）的IT资产和数据安全至关重要。 前言 随着互联网和云计算技术的发展，很多企业（组织）特别是中大型企业和互联网企业，保有了规模较大的IT基础设施，拥有并维护着数量较多的服务器。企业的业务运作在很大程度上依赖于IT基础设施的正常和稳定运行，为了确保IT基础设施的稳定运行，堡垒机成为了不可或缺的运维保障设施。那么，什么是堡垒机呢？ 什么是堡垒机 通常，根据内部计算机系统或网络的大小和安全等级要求的不同，会设置一台或多台计算机系统作为从外部网络访问内部系统和网络的入口，从而屏蔽内部计算机系统或网络，使其免受来自外部网络的 或其它安全漏洞的影响，进而保护敏感或私有的数据和网络的安全。这样的一台或多台计算机系统即被称为堡垒机。堡垒机是内部计算机系统或网络面向外部的唯一入口，亦即是说外部只有通过堡垒机才可以访问到内部计算机系统或网络，作为这样一种特殊用途的计算机系统，其必须通过专门的配置来抵御外部 ，满足一定的功能要求，从而发挥安全堡垒的作用。 作为内部计算机系统或网络的唯一入口，堡垒机的重要性是显而易见的，对内部系统或网络的访问和运维将依赖于堡垒机，此种依赖对堡垒机的要求颇高----不仅仅是简单的跳板机，而是企业（组织）IT运维的中枢

很多人不知道Linux运维人员的工作职责到底是什么？ 老司机告诉你：正规的运维工作是什么的? 很多人不知道如何入门系统运维？** 前前后后写了多年的技术文章，也积累了一定数量的文章。只不过品类繁多，日前，民工哥将历史文章逐一划分，将其分类。目前已将运维工程师学习进阶所需技术点整理成文。 命名：《运维工程师打怪升级之路》 版本：V1.0版本「2019年1月20日发布」 V1.0.1版本「2019年4月26日更新」 内容概况： 内容由浅入深，从最基础的网络基础开始，逐渐深入系统的学习Linux系统运维知识。然后引入企业项目实战内容，从而让更多学习Linux系统运维的读者朋友们「无论前端、后端、测试还是运维，底层系统是必备技术点」，都能够快速入门、并且在一程度上掌握当下企业所需要的技术储备。再穿插企业面试题、面试经验等，同时也能帮助运维工程师们在求职的路上能更加顺畅，少踩坑。 后面会逐渐更新将其完善，希望能帮助到同为运维路上的技术人。 为什么写这样的系列文章呢？原因有以下几点： 太多人问我如何学习Linux系统？ 多数人不太注重学习方法 多数人不太注重学习是一个积累的过程 多数人不知如何循述渐进的学习一个技术点 到底学习Linux运维需要掌握哪些知识点 基于以上几点，我把公众号上的文章加以分类总结，然后结合个人的实际工作经验。所以，也才有这个系列文章《运维工程师打怪升级之路》。

在此之前，发布过两个版本： 运维工程师打怪升级之路 V1.0 版本发布 运维工程师打怪升级必经之路 V1.0.1 很多读者伙伴们反应总结的很系统、很全面，无论是0基础初学者，还是有基础的入门者，或者是有经验的职场运维工程师们，都反馈此系列文章非常不错！ 为了更好的提升可阅读性、可查找性，特此，将列与公众号菜单的系统系列文章，统一整理于一篇文章，按原来的整体架构，分类整理，也就是说，今后的更新与迭代不再是多级的菜单目录，统一是一篇完整的文章，有利于读者阅读与查找。 命名：《运维工程师打怪升级之路》 版本：V1.0版本「2019年1月20日发布」 V1.0.1版本「2019年4月26日更新」 V2.0版本 「2019年5月13日发布」 内容概况： 内容由浅入深，从最基础的网络基础开始，逐渐深入系统的学习Linux系统运维知识。然后引入企业项目实战内容，从而让更多学习Linux系统运维的读者朋友们「无论前端、后端、测试还是运维，底层系统是必备技术点」，都能够快速入门、并且在一程度上掌握当下企业所需要的技术储备。再穿插企业面试题、面试经验等，同时也能帮助运维工程师们在求职的路上能更加顺畅，少踩坑。 后面会逐渐更新将其完善，希望能帮助到同为运维路上的技术人。 运维工程师打怪升级进阶之路基础篇 1、网络基础 网络组建之路由基础 网络基础NAT（Network Address

前言 一个成熟的网站架构并不是一开始设计就具备高可用、高伸缩、高性能等特性的，它是随着用户量和业务线不断增加，基础架构才逐渐健壮的。在发展初期，一般都是从0到1，不会一上来就整一些大而全的架构，也很少人这么任性。 说明 适用业务：电商/门户/招聘网站 开发语言：PHP和JAVA Web服务：Nginx/Tomcat8 数据库：MySQL 操作系统：CentOS 物理服务器：Dell R730/R430 一、单台服务器部署 项目开发完成上线，用户访问量寥寥无几。 二、WEB与数据库独立部署 有一定用户访问量，单台服务器性能有些吃力，想提高并发能力，增加一台服务器，将HTTP请求与SQL操作负载分散不同服务器。 三、动静分离-初期 什么是动静分离？静态页面与动态页面分离部署。 四、数据库主从与查询缓存 RedisCache 使用Redis缓存数据库查询结果，将热数据放到内存中，提高查询速度，减少数据库请求。 MySQL主从 基于binlog异步复制。 HA MySQL：Keepalived 怎么保证Redis缓存时效性？ a) 增加中间件，在主从同步延迟时间内，中间件将SQL读操作还路由到主。 b) 主从同步延迟时间后，再异步发起一次淘汰Cache。 c) 增加消息队列和清理Cache程序，入库同时也写入消息队列，缓存清理程序订阅消息队列，一旦有数据更新，重新Cache。 d)