首页>>互联网>>DevOps->运维项目实例?

运维项目实例?

时间:2023-12-11 本站 点击:0

运维项目管理流程

运码衡维项目管理流程

导语:没有任何一个项目能轻而易举的成功。但是你却可以努力去争取更大的成功率,靠的便是精心设计、并且行之有效的流程管理。下面我为你整理的运维项目管理流程,希望对你有所帮助!

1、生命周期与方法论

这是项目的纪律,为项目开展划出了清晰的界限,以保证项目进程。生命周期主要是协调相关项目,而方法论为项目进程提供了持续稳定的方式方法。

生命周期通常由项目的阶段组成(包括:开始、规划、执行/控制、完成),或由工作的重复周期构成。项目生命周期的细节一般都会随具体业务、项目、客户要求而改变。因此即使在同一个项目中,周期也会有多种可能的变化。对工作细致度、文件管理、项目交付、项目沟通的要求体现在生命周期标准和考核的方方面面。滚咐大项目的阶段一般更多更长,而小项目的阶段少,考核点也少。

与生命周期类似,项目方法也因项目而易,细节关注程度高。产品开发项目的方法经常涉及使用何种工具或系统,以及如何使用。信息技术项目的方法包括版本控制标准、技术文档管理、系统开发的各个方面。

项目方法往往不是由项目团队自行确定,而由公司为所有项目设定。采用与否,其实项目团队没有太多选择。公司管理层设定的方法本身代表权威,也是你作为项目领导获得项目控制权的一个途径。考虑项目方法某方面的作用时,始终要把握其对项目人员管理的效率,即在可能出现问题的地方争取正面效应。

2、项目定义

清晰的项目描述决定了你的项目控制能力,因为接下来所有工作都在描述范畴之内。不管你如何并为何要进行描述,你要对你的项目进行书面定义,让项目各方和项目组随时参考。

项目定义的形式和名称各式各样,包括:项目章程、提案、项目数据表、工作报告书、项目细则。这些名称的共同点在于,项目主管方和其他相关各方面从上而下地传达了他们对项目的期大模纯待。清晰的项目定义还包括以下方面:

项目目标陈述 (一小段文字,对项目交付成果、工期、预期成本或人力进行高层次的描述)

项目回报(包括商业案例或投资分析的回报)

使用中的信息或客户需求

对项目范围进行定义,列出所有预期的项目成果

成本和时间预算目标

重大困难和假设

描述该项目对其他项目的依赖

高风险、所需的新技术、项目中的重大问题

努力将尽可能多的具体信息,囊括在项目描述或章程中,并使其在项目主管方和相关方面获得认可,进而生效。

3、合同与采购管理

不管你在你的组织内有多大的影响力和权力,你对受雇于其他公司的项目成员的影响会比较小。虽然不一定普遍适用,但你可以尽量不将项目工作外包,这是提高项目控制力的一个技巧。

在考虑启用合同商或外部顾问之前,对整体采购流程进行重检。寻找有服务合同起草经验并可以帮助你的人。

建立成功的外包关系需要时间和精力,这些工作要及早着手。为了不误项目工期,你要及时做到所有细节到位,所有合同及时签订。你打算外包哪部分项目交付成果,对这部分工作的细化就是你实施项目控制的着手点。记录这些细化内容、评估和接收标准、所有相关要求、必要时间规划。项目定义信息一定要包括在合同之内,相关责任及早确定。和所有你考虑到的供应商讨论这些要求,这样你的项目期望才会在各方之间明晰。

4、项目规划、执行、跟踪

作为项目领导,通过制定有力的规划、跟踪、执行流程,你可以建立项目控制的基础。争取各方面的.支持,进而在项目内全面推广。

让项目组成员参与规划和跟踪活动,这可以争取大家的支持并提高积极性。睿智的项目领导往往大范围地鼓励参与,并通过流程汇聚大家的力量。当大家看到自己的努力以及对项目的贡献被肯定的时候,项目很快就从“他们的项目”变成“我们的项目”。当项目成员视项目工作为己任的时候,项目控制就会简单得多。较之于漠不关心的团队,此时的项目管理成功几率更大。运用项目管理流程也会鼓励项目成员的合作,这也让你的项目控制工作更加轻松。

5、变化管理

技术性项目中问题最集中的方面就是缺少对具体变化的管理控制。要解决这个问题,需要在项目的各方面启用有效的变化管理流程。

解决方法可以很简单,例如被项目团队、项目主办方、相关方认可的流程图。这提醒了项目人员,变化在被接受之前会进行细致地考察,并且提高了变化提案的门槛。

审查变化提案的时候,要注意该提案是否对变化有清晰到位的描述。如果变化提案的动因描述得不清不楚,该提案就要打回去,并且要求对变化所带来的益处进行定量评估。对于那些仅局限于技术解决方案的变化提案,要多打几个问号,因为提案人也许不能全面地判断问题。如果变化提案过多地关注问题的解决,而不注重实际问题,打回去并要求关注具体的业务形势。

最后,如果不接受某变化提案,一定要做到有理有据。而且,对项目时间、成本、精力等其他相关因素所受的影响,进行合理的估计。

6、风险管理

风险管理的流程能让你制定出全面的规划,找出潜在的麻烦,就风险问题的解决方法达成一致,根除严重的问题。

风险管理要做到事半功倍,就要与项目规划同时进行。进行项目工作分解安排时,注意对项目活动的不恰当理解;分配项目任务和开展评估时,寻找风险;资源匮乏或项目资源不足,或项目工作依赖于某一个人时,要知道风险的存在。分析项目工作将遇到的困难,鼓励所有参与规划的人在规划过程中,设想最坏的情况和潜在困难。

7、质量管理

质量管理提供了另一套搭建项目结构的流程,保证项目领导提出的工作要求一个不落地执行到位。项目质量的标准分两类:行业内实行的全球质量标准,公司或项目独有的质量标准。

如果你的公司实行或接受了质量标准,要注意该标准对你和你的团队有何要求。具体而言,这些标准会包括ISO 9000标准或六西格玛。进而确定质检清单、质控流程及相关要求,并将其与你的项目规划进行整合。项目必须遵守的书面步骤、报告、评估,对团队成员是强有力的推动,让大家步调一致。标准比你的临时要求更有效。

质量管理流程还能将项目要求与客户心声联系起来。不管你说什么,只要是在传递客户或用户的要求,你都要加以强调。市场调查、标杆分析、客户访谈都是评估和记录用户需求并确定项目要求价值的好工具。

8、问题管理

项目开展过程中问题的出现不可避免。在项目初期,在资源、工期、优先事项等其他方面为项目的问题管理确定流程。争取让团队支持及时发现、跟踪、解决问题的流程规定。建立跟踪流程,记录当前问题。问题记录信息包括:问题描述、问题特征或表现(用于沟通)、开始时间、责任人、目前状态、预计结束时间。

处理待解决问题的流程很简单,包括列出新问题的流程、定期复查待解决的问题、处理老问题的方法。对于没有太多组织管理权的项目领导而言,问题跟踪流程的力量在于让其把握了问题状态和进度的实时信息。一旦问题责任人承诺了问题解决的时限,你可以任意公布问题解决过程中的变数。不管问题责任人是本项目成员,还是其他项目或部门的成员,谁都不乐意随时将自己的大名置于人们质疑的目光中。问题清单的公开使得掌握该清单的人获得一定的影响力和控制力。

9、决策

项目管理时时有决策,快速得当的决策对于项目控制至关重要。即使项目领导掌握了控制权,完善的集体决策流程仍然裨益颇多,因为共同决策能获得更多内部支持,效果自然会更好。

项目工作中的决策绝非易事,项目组内纷繁复杂的观点让决策更加困难。项目各方认同的问题解决流程可以简化决策的过程,照顾各方要求。

尽早和你的项目组一起设立决策流程,或采用现有流程,或对现有流程做适当的修改。好的决策流程能为你的项目控制提供强有力的支持。该流程应该包括以下步骤:

清楚地陈述必须解决的问题。

吸纳所有需要参与决策或将会受该决策影响的成员参与决策过程,这样可以争取团队支持。

与项目组一道重审项目陈述,必要时进行修正,让每位成员获得一致认识。

针对决策标准(如:成本、时间、有效性、完整性、可行性),开展头脑风暴或讨论。选择那些与计划目标关联的、可执行、可供项目各方参考供决策之用的标准。

与项目组一道确定各标准的权重(所有标准的权重总和为100个百分点)。

设定决策的时限,规定用于调查、分析、讨论、最终决策的时间。

开展头脑风暴,在规定时间内尽可能多地产生决策想法。多方发展整个项目组都能接受的想法。

通过集体投票的方法进行筛选,至多确定六个考虑项进行具体分析。分析其与决策标准的契合度。

理性对待讨论中出现的异议。有必要的话,可增加决策标准。

根据评估和权重标准,将这些选项进行排序。

考虑采用首位选项的结果。如果没有异议,则结束讨论并开始实施决策。

将决策写入文件,并与团队成员及项目相关方面沟通决策结果。

10、信息管理

这项是非常关键的资源,如何管理值得仔细思考。有的项目使用网站和网络服务器,或信息管理系统,进行项目重要信息的存储。有的项目则使用群件来维护项目文件,并提供电子邮件等服务。

不管你用何种方式存储项目数据,要保证所有项目成员能随时获得所需信息。将最新的项目文件存储在方便查找的位置,进行清楚地标记,及时删除过时信息。

;

linux运维工程师项目经验

linux运维项目经验可以从以下方面入手:

1、项目名称:简要描述项目的目的和范围。

2、角色描述:详细描述你在项目中所扮演的角色,包括你的职责和贡献。

3、技术栈:列出你在项目中使用的技术,包括操作系统、软件、工具等。

4、成就:描述你在项目中取得的成就,包括解决的问题、实现的功能、达成的目标等。

5、反思:总结你在项目燃滚中学到的经验教训皮基余,并分享你在今后的项目中如何使用这些经验。

项目经验案例

项目时间:2017-04 - 2017-04

项目名称:MySQL 主从复制,MHA 高可用 | 项目工具:centos6.5

项目描述:

项目介绍

公司的数据库没有做高可用,我们在使用脚本进行主从切换,觉得很麻烦,而且一旦宕机,后果不堪设想,老大要求有我们拿出一个方案,我们最后开会讨论拿出了MHA方案。

我的职责

1、保证数据安全,针对数据库单点问题。

2、根据实际情况开会讨论,确认高可用方案,使用 MHA 做障切换。

3、针对MHA进行研究。

4、根据需求,选用数据库备份方案,并进行恢复测试。

5、做好数据恢锋悄复解决方案。

IT运维是干嘛?能举个例子吗?

不同公司界定不同。

有些公司的IT运维是网络管理员,修理下打印巧戚机,员工电脑坏了给修理下,公司网络维护,各种公司内部和电子相关的都属于他管理,大部运丛分IT运维指的是这个。

还有些公司的it运维是负责服务器,linux,windows等等各种网站,以及旁宽樱各种应用,比如说qq的服务器,sina,baidu的服务器。都是哈。

vivo大规模Kubernetes集群自动化运维实践

一、背景

随着vivo业务迁移到k8s的增长,我们需要将k8s部署到多个数据中心。如何高效、可靠的在数据中心管理多个大规模的k8s集群是我们面临的关键挑战。kubernetes的节点需要对os、docker、etcd、k8s、cni和网络插件的安装和配置,维护这些依赖关系繁琐又容易出错。

以前集群的部署和扩缩容主要通过ansible编排任务,黑屏化操作、配置集群的inventory和vars执行ansible playbook。集群运维的主要困难点如下:

二、集群部署实践

2.1 集群部署介绍

主要基于ansible定义的OS、docker、etcd、k8s和addons等集群部署任务。

主要流程如下:

上面看到是集群一键部署关键流程。当在多个数据中心部署完k8s集群后,比如集群组件的安全漏洞、新功能的上线、组件的升级等对线上集群进行变更时,需要小心谨慎的去处理。我们做到了化整为零,对单个模块去处理。避免全量的去执行ansible脚本,增加维护的难度。针对如docker、etcd、k8s、network-plugin和addons的模块化管理和运维,需提供单独的ansible脚本入口,更加精细的运维操作,覆盖到集群大部分的生命周期管理。同时kubernetes-operator的api设计的时候可以方便选择对应操作斗游yml去执行操作。

集群部署优化操作如下:

(1)k8s的组件参数管理通过

ConmponentConfig[1]提供的API去标识配置文件。

(2)计划切换到kubeadm部署

(3)ansible使用规范

2.2 CI 矩阵测试

部署出来的集群,需要进行大量的场景测试和模拟。保证线上环境变更的可靠性和稳定性。

CI矩阵部分测试案例如下。

(1)语法测试:

(2)集群部署测试:

(3)性能和功能测试:

这里利用了GitLab、gitlab-runner[2]、ansible和kubevirt[3]等开源软件构建了CI流程。

详细的部署步骤如下:

如上图所示,当开发人员在GitLab提交PR时会触发一系列操作。这里空蠢销主要展示了创建虚拟机和集群部署。其实在我们的集群还部署了语法检查和性能测试gitlab-runner,通过这些gitlab-runner创建CI的job去执行CI流程。

具体CI流程如下:

如上图所示,当开发人员提交多个PR时,会在k8s集群中创建多个job,每个job都会执行上述的CI测试,互相不会档如产生影响。这种主要使用kubevirt的能力,实现了k8s on k8s的架构。

kubevirt主要能力如下:

三、Kubernetes-Operator 实践

3.1 Operator 介绍

Operator是一种用于特定应用的控制器,可以扩展 K8s API的功能,来代表k8s的用户创建、配置和管理复杂应用的实例。基于k8s的资源和控制器概念构建,又涵盖了特定领域或应用本身的知识。用于实现其所管理的应用生命周期的自动化。

总结 Operator功能如下:

3.2 Kubernetes-Operator CR 介绍

kubernetes-operator的使用很多自定义的CR资源和控制器,这里简单的介绍功能和作用。

【ClusterDeployment】 : 管理员配置的唯一的CR,其中MachineSet、Machine和Cluster它的子资源或者关联资源。ClusterDeployment是所有的配置参数入口,定义了如etcd、k8s、lb、集群版本、网路和addons等所有配置。

【MachineSet】 :集群角色的集合包括控制节点、计算节点和etcd的配置和执行状态。

【Machine】 :每台机器的具体信息,包括所属的角色、节点本身信息和执行的状态。

【Cluster】 :和ClusterDeployment对应,它的status定义为subresource,减少

clusterDeployment的触发压力。主要用于存储ansible执行器执行脚本的状态。

【ansible执行器】 :主要包括k8s自身的job、configMap、Secret和自研的job控制器。其中job主要用来执行ansible的脚本,因为k8s的job的状态有成功和失败,这样job 控制器很好观察到ansible执行的成功或者失败,同时也可以通过job对应pod日志去查看ansible的执行详细流程。configmap主要用于存储ansible执行时依赖的inventory和变量,挂在到job上。secret主要存储登陆主机的密钥,也是挂载到job上。

【扩展控制器】 :主要用于扩展集群管理的功能的附加控制器,在部署kubernetes-operator我们做了定制,可以选择自己需要的扩展控制器。比如addons控制器主要负责addon插件的安装和管理。clusterinstall主要生成ansible执行器。remoteMachineSet用于多集群管理,同步元数据集群和业务集群的machine状态。还有其它的如对接公有云、dns、lb等控制器。

3.3 Kubernetes-Operator 架构

vivo的应用分布在数据中心的多个k8s集群上,提供了具有集中式多云管理、统一调度、高可用性、故障恢复等关键特性。主要搭建了一个元数据集群的pass平台去管理多个业务k8s集群。在众多关键组件中,其中kubernetes-operator就部署在元数据集群中,同时单独运行了machine控制器去管理物理资源。

下面举例部分场景如下:

场景一:

当大量应用迁移到kubernets上,管理员评估需要扩容集群。首先需要审批物理资源并通过pass平台生成对应machine的CR资源,此时的物理机处于备机池里,machine CR的状态为空闲状态。当管理员创建ClusterDeploment时所属的MachineSet会去关联空闲状态的machine,拿到空闲的machine资源,我们就可以观测到当前需要操作机器的IP地址生成对应的inventory和变量,并创建configmap并挂载给job。执行扩容的ansible脚本,如果job成功执行完会去更新machine的状态为deployed。同时跨集群同步node的控制器会检查当前的扩容的node是否为ready,如果为ready,会更新当前的machine为Ready状态,才完成整个扩容流程。

场景二:

当其中一个业务集群出现故障,无法提供服务,触发故障恢复流程,走统一资源调度。同时业务的策略是分配在多个业务集群,同时配置了一个备用集群,并没有在备用集群上分配实例,备用集群并不实际存在。

有如下2种情况:

3.4 Kubernetes-Operator 执行流程

四、总结

vivo大规模的K8s集群运维实践中,从底层的集群部署工具的优化,到大量的CI矩阵测试保证了我们线上集群运维的安全和稳定性。采用了K8s托管K8s的方式来自动化管理集群(K8s as a service),当operator检测当前的集群状态,判断是否与目标一致,出现不一致时,operator会发起具体的操作流程,驱动整个集群达到目标状态。

当前vivo的应用主要分布在自建的数据中心的多个K8s集群中,随着应用的不断的增长和复杂的业务场景,需要提供跨自建机房和云的多个K8s集群去运行原云生的应用程序。就需要Kubernetes-Operator提供对接公有云基础设施、apiserver的负载均衡、网络、dns和Cloud Provider 等。需要后续不断完善,降低K8s集群的运维难度。

本文作者:Zhang Rong 来源:vivo互联网技术

CIO之家 微信公众号:imciow

纯干货!python 在运维中的应用 (一):批量 ssh/sftp

日常工作中需要大量、频繁地使用ssh到服务器查看、拉取相关的信息或者对服务器进行变更。目前公司大量使用的shell,但是随着逻辑的复杂化、脚本管理的精细化,shell已经不满足日常需求,于是我尝试整合工作中的需求,制作适合的工具。 由于管理制度的缺陷,我以工作流程为核心思考适合自己的运维方式,提升工作效率,把时间留给更有价值的事情。 完整代码在最后,请大家参考。

生产:4000+物理服务器,近 3000 台虚拟机。

开发环境:python3.6、redhat7.9,除了paramiko为第三方模块需要自己安装,其他的直接import即可。

批量执行操作是一把双刃剑。批量执行操作可以提升工作效率,但是随之而来的风险不可忽略。

风险案例如下:

挂载很多数据盘,通常先格式化硬盘,再挂载数据盘,最后再写入将开机挂载信息写入/etc/fstab文件。在批量lsblk检查硬盘信息的时候发现有的系统盘在/sda有的在/sdm,如果不事先检查机器相关配置是否一致直接按照工作经验去执行批量操作,会很容易造成个人难以承受的灾难。

在执行批量操作时按照惯例:格式化硬盘-挂载-开机挂载的顺序去执行,假设有的机器因为某些故障导致格式化硬盘没法正确执行。在处理这类问题的时候通常会先提取出失败的ip,并再按照惯例执行操作。运维人员会很容易忽略开早虚机挂载的信息已经写过了,导致复写(这都是血和泪的教训)。

所以,为了避免故障,提升工作效率,我认为应当建立团队在工作上的共识,应当遵守以下原则:

当然,代码的规范也应当重视起来,不仅是为了便于审计,同时也需要便于溯源。我认为应当注意以下几点:

1、ssh no existing session,sftp超时时间设置:

在代码无错的情况下大量ip出现No existing session,排查后定位在代码的写法上,下面是一个正确的示例。由于最开始没考虑到ssh连接的几种情况导致了重写好几此睁纳遍。另外sftp的实例貌似不能直接设置连接超时时间,所以我采用了先建立ssh连接再打开sftp的方法。

2、sftp中的get()和put()方法仅能传文件,不支持直接传目录:

不能直接传目录,那换个思路,遍历路径中的目录和文件,先创建目录再传文件就能达到一样的效果了。在paramiko的sftp中s方法可以获取远程路径中的文件、目录信息。那么我们可以写一个递归来遍历远程路径中的所有文件和目录(传入一个列表是为了接收递归返回的值)。

python自带的os模块中的os.walk()方法可以遍历到本地路径中的目录和文件。

3、多线程多个ip使用s方法时无法并发。

改成多进程即可。

4、多个ip需要执行相同命令或不同的命令。

由于是日常使用的场景不会很复杂,所以借鉴了ansible的playbook,读取提前准备好的配置文件即可,然后再整合到之前定义的ssh函数中。

同时,我们还衍生出一个需求,既然都要读取配置,那同样也可以提前把ip地址准备在文件里。正好也能读取我们返回的执行程序的结果。

参数说明:

密码认证:

公钥认证:

可以配合 grep,awk 等命令精准过滤。

个人认为 Python 在初中级运维工作中的性质更像是工具,以提升工作效率森没、减少管理成本为主。可以从当前繁琐的工作中解脱出来,去 探索 更有价值的事情。python 本质上并不会减少故障的产生,所以在不同的阶段合理利用自身掌握的知识解决当前最重要的痛点,千万不要本末倒置。


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:/DevOps/23377.html