开发和运维的关系,实施和运维的区别_运维和开发的区别

随着网络的发展,想要把企业网站建设好,建设完成后运营好实现盈利,就需要很多人员的支持,其中运维岗位和开发岗位尤其重要。

说到运维,基本上应该是甲方职位了 ,乙方一般是研发和实施。从基层职位看,运维和开发(含产品经理)的分工还是挺大的。开发负责coding,主要考虑功能和非功能的实现,运维负责系统上线后系统的稳定、高效运行。所以在所需技术上也大有不同。

开发重点在各种开发语言、开发框架、持续性集成环境、软件工程、算法以及对应的业务等等,对底层的运行环境操心的不太多,尤其上了云环境之后,越来越少操心负载均衡、高可用这些非功能需求。

运维的重点在于系统运行的各种环境,从机房、网络、存储、物理机、虚拟机这些更基础的架构,到数据库、中间件平台、云平台、大数据平台,偏重的也不是编程,而是对这类平台的使用和管理。

所以开发重建设、运维当然就是维护。所以运维比开发更不受重视也是可以理解的,很难出彩,不出事就是成绩,尽管付出的努力并不少,甚至更多。看过产品运营的人说过一句话“不要管开发做出的是什么垃圾产品,留住客户才是运维关心的“但是在高层考虑中,尽管运维仍然受重视程度比不上开发,但已经不仅仅是考虑要尽快满足业务需求的问题了。

基础架构越来越有话语权。一方面,确实这个是很耗钱的事情(有钱就有话语权)。开发个系统不是有代码就能运行的,养个机房(特别是高端机房),动辄投资也得上亿,上千台服务器也不是那么容易管的,每年的折旧、报废也是钱啊,光电费也够养几个高级RD了。

另一方面基础架构,特别云化之后,更是要制约开发使用的语言和程序架构。还有越来越受重视的安全管理,更是巨大的投资,甚至上升到维稳层面。

但是总体来说,运维工程师是IT的后台,IT是一般甲方业务的后台。所以,重要是很重要,但是可能永远不如RD受重视。当然,小部分运维也很受重视,比如制造业,但毕竟是少数。

不管是运维工程师,还是开发工程师都是企业转型互联网、建设网站运营网站过程中不过缺少的人员,虽有职位之分,但是缺一不可,想要整个项目顺利运行,必须处理好各环节之间的关系。

而系统运维工程师从硬件到软件逐级向上可大概分为:

1、布线工程师、机房工程师:负责机房布线和机房里设备维护

2、驻场工程师:由乙方派到甲方公司的驻场工程师

3、实施工程师:由乙方派到甲方做实施

4、桌面运维工程师:维护笔记本电脑、邮箱等

5、网络运维工程师:负责网络运维

6、系统运维工程师:主要负责操作系统、数据库、中间件、虚拟化等

7、数据库运维工程师:负责数据库运维

8、运维开发工程师:负责DevOps的运维开发

9、应用运维工程师:负责应用运维

可以看到实施工程师是运维工程师里的一种。

一般所说的运维工程师和实施工程师有以下区别

一、工作内容不同

实施工程师包括常用操作系统、应用软件及公司所开发的软件安装、调试、定制开发及维护,还有少部分硬件、网络的工作; 负责现场培训: 现场软件应用培训; 协助项目验收; 负责需求的初步确认; 负责项目维护。

运维工程师要对公司硬件和软件进行维护。 硬件包括:机房、机柜、网线光纤、PDU、服务器、网络设备、安全设备等。

二、职能不同

实施工程师负责工程实施, 负责现场培训。

运维工程师负责服务的稳定性,确保服务可以不间断地为用户提供服务。

三、工作形式不同

实施工程师主要在外地跑,哪里有项目就要去哪里,工作一般包括:服务器硬件安装,上架、上电、初始化、升级BIOS、安装操作系统、做虚拟化、安装数据库、中间件、业务软件等。因为产品销售出去后,如何安装,如何布置,如何录入初始信息,这些事情都需要实施工程师去处理。

运维工程师要对公司硬件和软件进行维护。 硬件包括:机房、机柜、网线光纤、PDU、服务器、网络设备、安全设备等

软件包括:

1、系统运维软件:

  • 操作系统:Linux、Windows
  • 数据库:Oracle、Mysql、SQL Server、非结构化数据库
  • 中间件:Weblogic、Tomcat等
  • 虚拟化:VMware、KVM等
  • 云平台:Openstack、Docker等

2、系统运维支持软件:

  • 监控系统:监控机房、硬件、操作系统、数据库、中间件等
  • 备份系统:备份重要数据
  • 身份认证管理系统:也叫4A系统,认证Authentication、授权Authorization、记账Accounting、审计Audit
  • CMDB系统:CMDB存储与管理企业IT架构中设备的各种配置信息
  • ITSM系统:IT服务管理系统一套帮助企业对IT系统的规划、研发、实施和运营进行有效管理的系统,可管理问题工单、变更工单、事件工单等。
  • 自动化运维系统->智能化运维系统
  • 私有云系统

3、业务系统: 企业的业务系统,比如核心业务系统、APP、网站、ERP系统、CRM系统等

网络安全学习路线&学习资源

在这里插入图片描述

网络安全的知识多而杂,怎么科学合理安排?

下面给大家总结了一套适用于网安零基础的学习路线,应届生和转行人员都适用,学完保底6k!就算你底子差,如果能趁着网安良好的发展势头不断学习,日后跳槽大厂、拿到百万年薪也不是不可能!

初级网工

1、网络安全理论知识(2天)

①了解行业相关背景,前景,确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。(非常重要)

2、渗透测试基础(一周)

①渗透测试的流程、分类、标准
②信息收集技术:主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理,利用方法、工具(MSF)、绕过IDS和反病毒侦察
④主机攻防演练:MS17-010、MS08-067、MS10-046、MS12-20等

3、操作系统基础(一周)

①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全(系统入侵排查/系统加固基础)

4、计算机网络基础(一周)

①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析(HTTP、TCP/IP、ARP等)
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御:主动/被动攻击、DDOS攻击、CVE漏洞复现

5、数据库基础操作(2天)

①数据库基础
②SQL语言基础
③数据库安全加固

6、Web渗透(1周)

①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具:Nmap、BurpSuite、SQLMap、其他(菜刀、漏扫等)

恭喜你,如果学到这里,你基本可以从事一份网络安全相关的工作,比如渗透测试、Web 渗透、安全服务、安全分析等岗位;如果等保模块学的好,还可以从事等保工程师。薪资区间6k-15k

到此为止,大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗?

“脚本小子”成长进阶资源领取

7、脚本编程(初级/中级/高级)

在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别
在实际的渗透测试过程中,面对复杂多变的网络环境,当常用工具不能满足实际需求的时候,往往需要对现有工具进行扩展,或者编写符合我们要求的工具、自动化脚本,这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中,想要高效地使用自制的脚本工具来实现各种目的,更是需要拥有编程能力.

零基础入门,建议选择脚本语言Python/PHP/Go/Java中的一种,对常用库进行编程学习;
·搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP, IDE强烈推荐Sublime;
·Python编程学习,学习内容包含:语法、正则、文件、 网络、多线程等常用库,推荐《Python核心编程》,不要看完;
·用Python编写漏洞的exp,然后写一个简单的网络爬虫;
·PHP基本语法学习并书写一个简单的博客系统;
·熟悉MVC架构,并试着学习一个PHP框架或者Python框架 (可选);
·了解Bootstrap的布局或者CSS。

8、超级黑客

这部分内容对零基础的同学来说还比较遥远,就不展开细说了,贴一个大概的路线。感兴趣的童鞋可以研究一下,不懂得地方可以【点这里】加我耗油,跟我学习交流一下。

网络安全工程师企业级学习路线

如图片过大被平台压缩导致看不清的话,可以【点这里】加我耗油发给你,大家也可以一起学习交流一下。

一些我自己买的、其他平台白嫖不到的视频教程:

需要的话可以扫描下方卡片加我耗油发给你(都是无偿分享的),大家也可以一起学习交流一下。

在这里插入图片描述

结语

网络安全产业就像一个江湖,各色人等聚集。相对于欧美国家基础扎实(懂加密、会防护、能挖洞、擅工程)的众多名门正派,我国的人才更多的属于旁门左道(很多白帽子可能会不服气),因此在未来的人才培养和建设上,需要调整结构,鼓励更多的人去做“正向”的、结合“业务”与“数据”、“自动化”的“体系、建设”,才能解人才之渴,真正的为社会全面互联网化提供安全保障。

特别声明:

此教程为纯技术分享!本书的目的决不是为那些怀有不良动机的人提供及技术支持!也不承担因为技术被滥用所产生的连带责任!本书的目的在于最大限度地唤醒大家对网络安全的重视,并采取相应的安全措施,从而减少由网络安全而带来的经济损失!!!、

<think>嗯,用户现在想了解运维开发(DevOps)开发运维(DevOps)之间的区别。不过实际上,这两个术语可能是指同一个概念,或者有细微的不同。先看看用户提供的引用内容。引用里提到运维平台开发传统后端开发区别,还有运维开发需要综合技能。用户可能混淆了“运维开发开发运维”,虽然这两个词顺序不同,但可能指向不同的职责。 首先,根据引用1,运维开发属于运维的一部分,需要懂系统、网络等基础知识,而不同岗位如DBA有各自的专长。引用2比较了运维平台开发传统后端开发,提到运维平台开发更关注运维痛点,需要稳定性,而传统后端开发侧重业务需求快速迭代。引用3则强调运维开发的系统思维适应变化的能力。 用户的问题是要对比运维开发开发运维,可能指的是DevOps中的不同侧重。通常来说,DevOps是开发运维的结合,但有时“运维开发”可能偏向运维侧的自动化,而“开发运维”可能更强调开发侧的运维支持。需要明确这两个术语的定义,可能用户认为它们是不同的职位或角色。 需要结合之前的回答,之前我解释了运维开发的职责,包括CI/CD、自动化、监控等,现在用户想进一步了解与开发运维区别。根据引用2提到的,运维平台开发与传统后端开发区别,可能类似这里的对比。即运维开发更偏向于解决运维的自动化需求,而开发运维可能指开发人员参与运维工作,如使用K8s部署等,属于DevOps的一部分。 要确保回答结构清晰,职责对比明确。可能需要从职责、技能侧重、协作对象、目标等方面展开。例如,运维开发属于运维团队,主要负责工具平台开发;而开发运维属于开发团队,负责应用的运维支持。但需要确认是否存在这样的区分,或者是否都是DevOps的不同方面。 另外,用户可能希望了解这两个角色在项目中的具体职责差异,例如谁负责CI/CD管道,谁负责编写自动化脚本,谁负责监控系统等。根据引用2,运维平台开发与SRE团队协作,需求来自运维痛点,而传统后端开发来自业务方。因此,可能运维开发更接近运维,而开发运维更接近开发,但两者在DevOps文化下界限模糊。 最后需要总结两者的区别融合趋势,如引用2提到的DevOps文化下界限模糊,新兴领域需要综合技能。确保回答涵盖这些点,并且用用户提供的引用支持观点,比如引用2中的内容。</think>### 运维开发(DevOps Engineering)与开发运维(DevOps)的对比分析 虽然“运维开发开发运维”在中文表述上看似顺序不同,但在实际工作中,两者均属于**DevOps文化**的实践范畴,核心目标是通过**开发运维的协作**提升交付效率与系统稳定性。以下从职责、技能侧重点、协作模式等维度进行详细对比: --- #### **一、职责定位差异** | **维度** | **运维开发(DevOps Engineering)** | **开发运维(DevOps)** | |---------------------|----------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------| | **核心目标** | 以**运维需求为核心**,开发工具与平台解决运维痛点(如自动化部署、监控告警)[^1]。 | 以**开发需求为核心**,将运维能力嵌入开发流程(如环境自愈、微服务治理)[^2]。 | | **需求来源** | 来自运维团队的实际问题(如手动操作低效、故障排查困难)[^2]。 | 来自业务开发团队的需求(如快速交付、灰度发布)[^2]。 | | **典型工作内容** | - 构建CI/CD流水线<br>- 开发监控告警系统<br>- 设计基础设施即代码(IaC)方案 | - 实现服务自愈机制<br>- 优化微服务架构的运维支持<br>- 集成安全扫描到开发流程 | --- #### **二、技能侧重点** | **技能领域** | **运维开发** | **开发运维** | |---------------------|----------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------| | **技术栈** | 强调**底层技术**(如Linux内核、网络协议、容器编排)**运维工具开发**(Python/Go)[^1]。 | 更关注**业务逻辑实现**(如微服务框架、API设计)与**云原生技术集成**(如K8s、Service Mesh)。 | | **稳定性要求** | 需严格测试工具对生产环境的影响(如权限控制、回滚机制)[^2]。 | 通过A/B测试渐进式发布验证功能,侧重快速迭代[^2]。 | | **典型工具** | Ansible/Puppet(配置管理)、Prometheus(监控)、ELK(日志分析) | Jenkins/GitLab CI(流水线)、Istio(服务治理)、Argo Rollouts(渐进式发布) | --- #### **三、协作模式对比** 1. **运维开发团队** - 与**SRE(站点可靠性工程)团队**紧密协作,解决运维场景的自动化需求(如批量服务器巡检工具开发)[^2]。 - 需深入理解运维知识(如TCP/IP协议栈、存储性能优化),开发成果直接影响系统稳定性。 2. **开发运维团队** - 与**业务开发团队**协同工作,将运维能力内嵌至开发流程(如自动生成监控埋点代码)。 - 需熟悉业务架构(如微服务拆分原则),推动开发人员采用运维最佳实践(如限流降级设计)[^3]。 --- #### **四、融合趋势与选择建议** 在DevOps文化推动下,两者的界限逐渐模糊: - **运维开发**需掌握业务架构知识(如微服务通信协议)以设计更贴合需求的工具; - **开发运维**需理解底层基础设施(如容器网络模型)以实现高效部署[^3]。 **职业选择参考**: - 若对**系统稳定性、底层技术**有强烈兴趣 → 侧重运维开发方向; - 若更关注**业务快速迭代、云原生技术** → 侧重开发运维方向[^2]。 --- ### 总结 二者本质上是DevOps实践的一体两面: - **运维开发**是**“从运维走向开发”**,通过技术手段解决运维效率问题; - **开发运维**是**“从开发走向运维”**,将运维能力前置到开发阶段。 最终目标均为缩短交付周期,提升系统可靠性[^3]。 ```python # 示例:开发运维场景中的自动化健康检查 import requests def service_health_check(endpoint): try: response = requests.get(endpoint, timeout=5) return response.status_code == 200 except Exception as e: print(f"Health check failed for {endpoint}: {str(e)}") return False # 集成到CI/CD流水线中 if not service_health_check("https://api.example.com/health"): raise RuntimeError("Service health check failed before deployment!") ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值