devops

ITIL IT服务管理（ITSM）最佳实践框架的新版本 ITIL 4 于2019年初发布，目前ITIL相关的专业资格认证已经全面转向v4版本了。ITIL 4在设计理念上较v3版本有很大的变化，这些变化总体上是积极、有益，也是与时俱新的。 下面先给大家展示下我在2020年5月份刚获取的ITIL 4 MP证书，然后再简要介绍下ITIL 4的知识框架。 ITIL 4 MP证书 ITIL 有用吗 这是老调重谈的一个话题，确实有些多说无益了，有用没用，也是见仁见智的事情。 我在这里，仅是为大家提供下面这样一个Servicenow公司网站的产品解决方案截图，图片中展示的是IT Workflows方案中的系列产品，包括有服务管理、运营管理、商业管理、资产管理、DevOps、安全运维以及风险、合规治理等。 关于servicenow公司的情况简单，大家可以自行搜索资料了解下。总之，这样一个以从事ITSM产品工具和解决方案起家，并快速发展成为世界领先的SaaS产品服务商的公司，很好地证明了ITIL管理思想的市场价值。 ITIL4 框架 ITIL v3的核心要素是服务生命周期，即服务策略、服务设计、服务转换与过渡、服务运营以及服务的持续改进。而在ITIL 4体系中，虽然继承了大部分的v3版本中的核心内容，但是在设计原则、指导思想以及方法论层面都做了更多的改进，很多内容都是在v3版本中没有的。 简单的说

引言 最近几年，大家一直在讨论各式各样的架构，如：高并发架构、异地多活架构、容器化架 构、微服务架构、高可用架构、弹性化架构。还有这些架构相关的管理型技术方法，如： DevOps 、应用监控、自动化运维、 SOA 服务治理、去 IOE 等等。面对这么多的纷乱复杂 的技术，很多团队都是一个个地去做这些技术，非常辛苦，但结果并不好。 分布式系统架构的目的 首先，我们需要搞清楚的是为什么需要分布式系统，而不是传统的单体架构。其实，使用 分布式系统主要有以下几个原因：  增加系统容量 ：随着业务量越来越大，而要能够应对越来越大的业务量时，一台机器 的性能已经无法满足业务的需求了，我们需要多台机器才能应对大规模的应用场景。 所以，我们需要垂直或水平拆分业务系统，让其变成一个分布式的架构。  加强系统可用性 ：由于业务变得越来越关键，需要提高整个系统架构的可用性，这就 意味着架构中不能存在单点故障。这样整个系统不会因为一台机器出现故障导致整体 不可用。所以需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用 性。 以上是整个分布式系统架构的主要目的，当然，它还具体一些其它方面的优势，比如：  模块化 ：分布式系统架构采用的是一个服务一个模块，所以系统模块重用性更高； 持续发布和提高效率：因为软件服务模块初拆分，开发的发布速度可以并行而变得更快；  扩展性高

1、前言 在当下微服务架构盛行的时代，用户希望应用程序时时刻刻都是可用，为了满足不断变化的新业务，需要不断升级更新应用程序，有时可能需要频繁的发布版本。实现"零停机"、“零感知”的持续集成(Continuous Integration)和持续交付/部署(Continuous Delivery)应用程序，一直都是软件升级换代不得不面对的一个难题和痛点，也是一种追求的理想方式，也是DevOps诞生的目的。 2、滚动发布 把一次完整的发布过程，合理地分成多个批次，每次发布一个批次， 成功后 ，再发布下一个批次，最终完成所有批次的发布。在整个滚动过程期间，保证始终有可用的副本在运行，从而平滑的发布新版本，实现 零停机(without an outage) 、用户 零感知 ，是一种非常主流的发布方式。由于其自动化程度比较高，通常需要复杂的发布工具支撑，而k8s可以完美的胜任这个任务。 3、k8s滚动更新机制 k8s创建副本应用程序的最佳方法就是部署(Deployment)，部署自动创建副本集(ReplicaSet)，副本集可以精确地控制每次替换的Pod数量，从而可以很好的实现滚动更新。 具体来说，k8s每次使用一个新的副本控制器(replication controller)来替换已存在的副本控制器，从而始终使用一个新的Pod模板来替换旧的pod模板。 大致步骤如下：

在大多数情况下，软件应用程序开发由于其规范性和复杂性而变得很耗时。 为了在短时间内交付高质量应用程序，软件开发人员正在遵循一套通用的实践，称为DevOps生命周期。 那么，DevOps在软件应用程序开发领域中扮演着什么角色？ 让我们深入了解其含义、用途以及DevOps生命周期中的每个关键阶段。 什么是DevOps 在DevOps之前，从业人员使用瀑布模型或敏捷开发模型进行软件项目开发：瀑布模型或顺序模型是软件开发生命周期（SDLC）中的一种开创性方法,在这个模型中，软件开发成为一个线性过程，不同的阶段和任务被依次定位；而敏捷开发涉及各种方法的使用和SDLC中多个团队的协作。瀑布模型的线性和敏捷开发的跨功能性无法确保快速、连续地交付无缺陷的软件应用程序。 软件行业日益清晰地认识到:为了按时交付软件产品和服务，开发和运维工作必须紧密合作。这样的情况下，DevOps应运而生。 DevOps是一个简单的缩写词，源于“development（开发）”和“Operation（运维）”两个词，它涉及以特定的方式实践应用程序开发的任务。更广泛地说，软件开发和IT运维的结合被称为DevOps。 DevOps的优势 DevOps在促进IT运维和软件开发之间的敏捷关系方面的有效性受到几个因素的支持。通过在软件开发和IT运维部门的多个业务部门内实现更好的通信

Redis提供了许多提高和维护高效内存数据库使用的工具。在无需额外配置应用层的前提下，Redis独特的数据类型、指令和命令调优就可以满足应用的需求，但是错误的配置，更确切的说那些机外设备可能导致操作麻烦和性能问题。虽然导致了一些令人头疼的问题，但是解决方案是存在的，而且解决方案可能比我们预期的简单。 本系列文章介绍了使用Redis时遇到的一些令人头疼的问题，以及该解决这些问题。这些内容基于我们在运行上千个Redis数据库实例时的真实经历。 复制缓冲区限制 复制缓冲区主从服务器同步数据时保存数据的内存区域。在一个完整的主从同步中，初始化阶段同步时，主服务器在复制缓冲区中保存数据的变化。初始化阶段完成后，缓冲的内容发送到从服务器。这个过程可能会遇到缓冲区的容量限制，达到最大容量时复制会重新开始。为了避免这种情况，缓冲区需要依据复制过程中变化的类型和数量进行初始化配置。例如，一个小缓冲区可以存储少量的变化数据，但当变化比较多、比较大时，我们需要大缓冲区。一个更复杂的解决方案会更详细的设置缓冲区，避免冗长、大的复杂过程耗尽缓冲区（如果缓冲区太小）。最终，这个解决方案需要微调特定的数据库。 当256MB的硬限制到达时，或者软限制到达且持续60秒时，默认的复制链路会断裂（导致同步从头开始）。许多情况下，特别是写负载高和从服务器带宽不足的情况下，负载过程都无法结束。这可能导致无限循环

角色划分 在Elasticsearch中，有很多角色，常用的角色有如下： Master Node ：主节点 Master eligible nodes ：合格节点 Data Node ：数据节点 Coordinating Node ：协调节点 Ingest Node ：ingest节点 三种角色由elasticsearch.yml配置文件中的node.master、node.data等来控制 Master Node ：主节点，该节点不和应用创建连接，每个节点都保存了集群状态，master节点不占用磁盘IO和CPU，内存使用量一般。 Master eligible nodes ：合格节点，每个节点部署后不修改配置信息，默认就是一个 eligible 节点，该节点可以参加选主流程，成为Mastere节点。该节点也保存了集群节点的状态。eligible节点比Master节点更节省资源，因为它还未成为 Master 节点，只是有资格成功Master节点。 Data Node ：数据节点，该节点和索引应用创建连接、接收索引请求，该节点真正存储数据，ES集群的性能取决于该节点的个数（每个节点最优配置的情况下），data节点会占用大量的CPU、IO和内存。 Coordinating Node ：协调节点，该节点和检索应用创建连接、接受检索请求，但其本身不负责存储数据，可当负责均衡节点

概述 上周发了一篇 AutoUpdater迁移到Github ， 主要目的是熟悉当前社区写文章的流程以及GitHub的开源和发布流程，另外也开始回归社区，准备多写一些技术文章，多开源项目，顺带把这几年造的轮子也一一开源，我深信有开源才有进步，一味闭门造车只会逐渐被时代所淘汰。 前几天查看博客与邮箱，发现很多朋友发的邮件或者博客留言，由于最近几年一直忙于工作，所以没有及时一一回复，在此也统一表示抱歉，希望后面有更多的时间来回答各位的问题。 也有朋友想了解新加坡IT现状和薪酬情况，我觉得三言两语可能无法完全讲清楚，就干脆写几篇文章来详细聊聊。 新加坡互联网发展程度比不了美国及国内，公司也没有美国和国内那么多, 没有硅谷的巨头FAANG（Facebook，Amazon，Apple，Netflix和Google），也没有国内耳熟能详的BATJM（百度、阿里、腾讯、京东、美团）以及拼多多，字节跳动， IT市场规模相对来讲要小很多，主要IT企业可以分为以下几类，薪酬依次递减： 第一类是美系巨头在亚太的总部和研发中心。 第二类是金融企业（三家本地银行， 投资银行， 大大小小的几十家外资银行，二十多家保险公司）。 第三类是最近几类才发展起来的独角兽企业，如Grab， SEA等。 第四类是IT相关的项目外包或人力外包公司。 第五类是新加坡IT相关的初创公司。 第六类是新加坡其他行业的IT部门。

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 简介： 跟郭旭东聊过之后，我对程序员的敬佩又多一分。这个92年的开发者，难能可贵地兼备朝气蓬勃的技术能量与长远深刻的行业洞见。独自承担DevOps平台从0到1的所有工作，我打趣说超级开发者不过如此，他却谦虚地表示差得还远，始终在学习。业余生活几乎都在撸猫遛狗的铲屎官，在云原生也有自己的一片天地。 以下为郭旭东的专访内容，欢迎收看（约4分钟）。 自我驱动，成就非凡 我负责开发自研的DevOps平台Varian，可以说是工作中遇到过的最大难题了。整个平台由我一手搭建，从技术选型、产品设计，到代码编写、开发测试，甚至营销宣传的工作也要自己来做。对于一个习惯根据需求文档来写代码的程序员来说，是很恐怖的一件事，甚至接到任务的第一天就怕到想跑路了。但是领导的一句话：“怕什么，放手去干，做砸了也不会怪你”，给了我很大的信心，于是就放开手脚，大胆去干，反而后来越做越好了。 当时整个项目只有我一个人做，准确点说，整个部门只有我一个运维开发，其他都是从事业务开发的Java程序员，我兼任了产品、开发、测试、运维等所有角色。本身我只是一名后端开发，前端的内容也要捡起来现学，从页面的设计到实现的功能，都要一个人解决。这些技术的问题还好解决，最难的角色转换其实是产品，每天都要想方设法地给自己提需求

作者：Pawan Shankar 翻译： Bach （才云） 校对： bot （才云）、 星空下的文仔 （才云） 现在很多团队面临着这么一个挑战：如何在不减慢应用交付速度的情况下，管理好安全风险。有种方法可以解决该问题，就是 采用安全的 DevOps 工作流程 。 安全的 DevOps（也称为 DevSecOps）会在从开发到生产的整个应用程序生命周期中提供安全性以及监控功能，帮助我们交付安全、稳定和高性能的应用程序。如果我们把该工作流程插入现有的工具链中，可以为 DevOps、开发人员和安全团队最大程度地提高效率。 DevSecOps 五个基本工作流程包括镜像扫描、运行安全、合规性、Kubernetes 和容器的监控以及应用程序和云服务监控。 镜像扫描是嵌入到 DevSecOps 工作流程中的一项关键功能。作为第一道防线，它可以帮助我们在漏洞被利用之前检测到漏洞并阻止，另外，它还易于实现并可自动化。本文将介绍多个镜像扫描的最佳实践和技巧，帮助大家采用有效的容器镜像扫描策略。 K8sMeetup 什么是容器镜像扫描 镜像扫描是指分析容器镜像的内容和构建过程，以检测安全问题、漏洞或错误实践。 我们可以从多个 Feed（NVD、Alpine、Canonical 等）中收集“通用漏洞披露（CVE）”信息，以检查镜像是否容易受到***，其中有些还提供了开箱即用的扫描规则

1、前言 在当下微服务架构盛行的时代，用户希望应用程序时时刻刻都是可用，为了满足不断变化的新业务，需要不断升级更新应用程序，有时可能需要频繁的发布版本。实现"零停机"、“零感知”的持续集成(Continuous Integration)和持续交付/部署(Continuous Delivery)应用程序，一直都是软件升级换代不得不面对的一个难题和痛点，也是一种追求的理想方式，也是DevOps诞生的目的。 2、滚动发布 把一次完整的发布过程，合理地分成多个批次，每次发布一个批次， 成功后 ，再发布下一个批次，最终完成所有批次的发布。在整个滚动过程期间，保证始终有可用的副本在运行，从而平滑的发布新版本，实现 零停机(without an outage) 、用户 零感知 ，是一种非常主流的发布方式。由于其自动化程度比较高，通常需要复杂的发布工具支撑，而k8s可以完美的胜任这个任务。 3、k8s滚动更新机制 k8s创建副本应用程序的最佳方法就是部署(Deployment)，部署自动创建副本集(ReplicaSet)，副本集可以精确地控制每次替换的Pod数量，从而可以很好的实现滚动更新。 具体来说，k8s每次使用一个新的副本控制器(replication controller)来替换已存在的副本控制器，从而始终使用一个新的Pod模板来替换旧的pod模板。 大致步骤如下：