四川轻化工大学专升本物联网工程专业介绍？

专升本快速报名和免费咨询：>

一、什么是大型网站运维

首先明确一下，全文所讲的”运维“是指：大型网站运维，与其它运维的区别还是蛮大的；然后我们再对大型网站与小型网站进行范围定义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器量级、pv量等考虑，其它因素不是重点；因此，我们先定义服务器规模大于1000台，pv每天至少上亿（至少国内排名前10），如sina、、，renrencom等等；其它小型网站可能没有真正意义上的运维工程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统、开发工作于一身的“复合性人才”，就如有些公司把一些合同采购都纳入了运维职责范围，还有如IDC网络规划也纳入运维职责。所以，非常重要一定需要明白：运维对其它关联工种必须非常了解熟悉：网络、系统、系统开发、存储，安全,DB等；我在这里所讲的运维工程师就是指专职运维工程师。

我们再来说说一般产品的“出生”流程：

1、首先公司管理层给出指导思想，PM定位市场需求（或copy成熟应用）进行调研、分析、最终给出详细设计。

2、架构师根据产品设计的需求，如pv大小预估、服务器规模、应用架构等因素完成网络规划,架构设计等（基本上对网络变动不大，除非大项目）

3、开发工程师将设计code实现出来、测试工程师对应用进行测试。

4、好，到运维工程师出马了，首先明确一点不是说前三步就与运维工作无关了，恰恰相反，前三步与运维关系很大：应用的前期架构设计、软/硬件资源评估申请采购、应用设计性能隐患及评估、IDC、服务性能安全调优、服务器系统级优化（与特定应用有关）等都需运维全程参与，并主导整个应用上线项目；运维工程师负责产品服务器上架准备工作，服务器系统安装、网络、IP、通用工具集安装。运维工程师还需要对上线的应用系统架构是否合理、是否具备可扩展性、及安全隐患等因素负责，并负责最后将产品（程序）、网络、系统三者进行拼接并最优化的组合在一起，最终完成产品上线提供用户使用，并周而复使：需求->开发（升级）->测试->上线（性能、安全问题等之前预估外的问题随之慢慢就全出来了）在这里提一点：网站开发模式与传统软件开发完全不一样，网站一天开发上线1~5个升级版本是家常便饭，用户体验为王嘛，如果某个线上问题像M$需要1年解决，用户早跑光了；应用上线后，运维工作才刚开始，具体工作可能包括：升级版本上线工作、服务监控、应用状态统计、日常服务状态巡检、突发故障处理、服务日常变更调整、集群管理、服务性能评估优化、数据库管理优化、随着应用PV增减进行应用架构的伸缩、安全、运维开发工作：

a、尽量将日常机械性手工工作通过工具实现（如服务监控、应用状态统计、服务上线等等），提高效率。

b、解决现实中服务存在的问题，如高可靠性、可扩展性问题等。

c、大规模集群管理工具的开发，如1万台机器如何在1分钟内完成密码修改、或运行指定任务？2000台服务器如何快速安装 *** 作系统？各分布式IDC、存储集群中数PT级的数据如何快速的存储、共享、分析？等一系列挑战都需运维工程师的努力。

在此说明一下其它配合工种情况，在整个项目中，前端应用对于网络/系统工程师来说是黑匣子，同时开发工程师职责只是负责完成应用的功能性开发，并对应用本身性能、安全性等应用本身负责，它不负责或关心网络/系统架构方面事宜，当然软/硬件采购人员等事业部其它同事也不会关心这些问题，各司其职，但项目的核心是运维工程师~！所有其它部门的桥梁。

上面说了很多，我想大家应该对运维有一些概念了，在此打个比方吧，如果我们是一辆高速行驶在高速公路上的汽车，那运维工程师就是司机兼维修工，这个司机不简单，有时需要在高速行驶过程中换轮胎、并根据道路情况换档位、当汽车速度越来越快，汽车本身不能满足高速度时对汽车性能调优或零件升级、高速行进中解决汽车故障及性能问题、时刻关注前方安全问题，并先知先觉的采取规避手段。这就是运维工作~！

最后说一下运维工程师的职责：”确保线上稳定“，看似简单，但实属不容易，运维工程师必须在诸多不利因素中进行权衡：新产品模式对现有架构及技术的冲击、产品高频度的升级带来的线上BUG隐患、运维自动化管理承度不高导致的人为失误、IT行业追求的高效率导致流程执行上的缺失、用户增涨带来的性能及架构上的压力、IT行业宽松的技术管理文化、创新风险、互联网安全性问题等因素，都会是网站稳定的大敌，运维工程师必须把控好这最后一关，需具体高度的责任感、原则性及协调能力，如果能做到各因素的最佳平衡，那就是一名优秀的运维工程师了。

另外在此聊点题外话，我在这里看到有很多人要sina、、,51com等聊自已的运维方面的经验，其实这对于它们有点免为其难：

a、各公司自已网络架构、规模、或多或少还算是公司的核心秘密，要保密，另外，对于大家所熟知的通用软件、架构，由于很多公司会根据自已实际业务需要，同时因为原版性能、安全性、已知bug、功能等原因，进行过二次开发（如apache,php,mysql）， *** 作系统内核也会根据不同业务类型进行定制的，如某些应用属于运算型、某些是高IO型、或大存储大内存型。根据这些特点进行内核优化定制，如sina就在memcache上进行过二次开发，搞出了一个MemcacheDB，具体做得如何我们不谈，但开源了，是值得称赞的，国内公司对于开源基本上是索取，没有贡献；另外，服务器也不是大家所熟知的型号，根据业务特点，大部份都是找DELL/HP/ibm进行过定制；另外，在分布式储存方面都有自已解决方案，要不就是使用现成开源hadoop等解决方案，或自已开发。但90%都是借鉴googleGFS的思想:分布式存储、计算、大表。

c、如上面所讲，目前大型网站运维还处于幼年时期理念和经验都比较零散，没有成熟的知识体系，可能具体什么是运维，大家都要先思索一番，或压根没想过，真正讨论也只是运维工作的冰山一角，局限于具体技术细节，或某某著名网站大的框架，真正运维体系化东西没有，这也许是目前网上运维相关资料比较少的原故吧。或者也是国内运维人员比较难招，比较牛的运维工程师比较少见的原因之一吧。

二、运维工作师需要什么样的技能及素质

做为一名运维工程师需要什么样的技能及素质呢，首先说说技能吧，如大家上面所看到，运维是一个集多IT工种技能与一身的岗位，对系统->网络->存储->协议->需求->开发->测试->安全等各环节都需要了解一些，但对于某些环节需熟悉甚至精通，如系统(基本 *** 作系统的熟悉使用,nix,windows)、协议、系统开发(日常很重要的工作是自动运维化相关开发、大规模集群工具开发、管理）、通用应用（如lvs、ha、webserver、db、中间件、存储等）、网络,IDC拓朴架构；

技能方面总结以下几点：

1、开发能力，这点非常重要，因为运维工具都需要自已开发，开发语言：c/c++（必备其中之一）、perl、python、php（其中之一）、shell（awk,sed,expect等），需要有过实际开发经验，否则工作会非常痛苦。

2、通用应用方面需要了解： *** 作系统（目前国内主要是linux、bsd）、webserver相关(nginx,apahe,php,lig>

3、系统、网络、安全，存储，CDN，DB等需要相当了解，知道其相关原理。

个人素质方面：

1、沟通能力、团队协作：运维工作跨部门、跨工种工作很多，需善于沟通、并且团队协作能力要强；这应该是现代企业的基本素质要求了，不多说。

2、工作中需胆大心细：胆大才能创新、不走寻常路，特别对于运维这种新的工种，更需创新才能促进发展；心细，运维工程师是网站admin,最高线上权限者，一不小心就会遗憾终生或打入十八层地狱。

3、主动性、执行力、精力旺盛、抗压能力强：由于IT行业的特性，变化快；往往计划赶不上变化，运维工作就更突出了，比如国内各大公司服务器往往是全国各地，哪里便宜性价比高，就那往搬，进行大规模服务迁移（牵扯的服务器成百上千台），这是一个非常头痛的问题；往往时间非常紧迫，如限1周内完成，这种情况下，运维工程师的主动性及执行力就有很高的要求了：计划、方案、服务无缝迁移、机器搬迁上架、环境准备、安全评估、性能评估、基建、各关联部门扯皮,7X24小紧急事故响应等。

4、其它就是一些基本素质了：头脑要灵光、逻辑思维能力强、为人谦虚稳重、亲和力、乐于助人、有大局观。

5、最后一点，做网站运维需要有探索创新精神，通过创新型思维解决现实中的问题，因为这是一个处于幼年的职业（国外也一样，但比国内起步早点），没有成熟体系或方法论可以借鉴，只能靠大家自已摸索努力。

三、怎样才算是一个合格的运维工程师

1、保证服务达到要求的线上标准，如999%；保证线上稳定，这是运维工程师的基本责职所在。

2、不断的提升应用的可靠性与健壮性、性能优化、安全提升；这方面非常考验主动性、和创新思维。

3、网站各层面监控、统计的覆盖度，软件、硬件、运行状态，能监控的都需要监控统计，避免监控死角、并能实时了解应用的运转情况。

4、通过创新思维解决运维效率问题；目前各公司大部份运维主要工作还是依赖人工 *** 作干预，需要尽可能的解放双手。

5、运维知识的积累与沉淀、文档的完备性，运维是一个经验性非常强的岗位，好的经验与陷阱都需积累下来，避免重复性范错。

6、计划性和执行力；工作有计划，计划后想法设法达到目标，不找借口。

以上只是技术上的一些层面，当然个人意识也是很重要的。

四、运维职业的迷惘、现状与发展前景

运维岗位不像其它岗位，如研发工程师、测试工程师等，有非常明确的职责定位及职业规划，比较有职业认同感与成就感；而运维工作可能给人的感觉是哪方面都了解一些，但又都比上专职工程师更精通、感觉平时被关注度比较低（除非线上出现故障），慢慢的大家就会迷惘，对职业发展产生困惑,为什么会有这种现象呢？除了职业本身特点外，主要还是因为对运维了解不深入、做得不深入导致；其实这个问题其它岗位也会出现，但我发现运维更典型，更容易出现这个问题；

针对这个问题我谈一下网站运维的现状及发展前景（也在思考中，可能不太深入全面，也请大家斧正补充）

运维现状：

2、技术层次比较低；主要处于技术探索、积累阶段，没有型成体系化的理念、技术。

3、体力劳动偏大；这个问题主要与第二点有关系，很多事情还是依靠人力进行，没有完成好的提练，对于大规模集群没有成熟的自动化管理方法，在此说明一下，大规模集群与运维工作是息息相关的如果只是百十来台机器，那就没有运维太大的生存空间了。

4、优秀运维人才的极度缺乏；目前各大公司基本上都靠自已培养，这个现状导致行业内运维人才的流动性非常低，非常多好的技术都局限在各大公司内部，如google50万台机器科学的管理,或者国内互联公司top10的一些运维经验，这些经验是非常有价值的东西并决定了一个公司的核心竞争力；这些问题进而导致业内先进运维技术的流通、贯通、与借签，并最终将限制了运维发展。

5、很多优秀的运维经验都掌握在大公司手中；这不在于公司的技术实力，而在于大公司的技术规模、海量PV、硬件规模足够大，如可怕的流量、51com海量数据~~~~这些因素决定了他们遇到的问题都是其它中/小公司还没有遇到的，或即将遇到。但大公司可能已有很好的解决方案或系统。

发展前景：

1、从行业角度来看，随着中国互联网的高速发展（目前中国网民已跃升为全球第一）、网站规模越来越来大、架构越来越复杂；对专职网站运维工程师、网站架构师的要求会越来越急迫,特别是对有经验的优秀运维人才需求量大，而且是越老越值钱；目前国内基本上都是选择毕业生培养（限于大公司），培养成本高，而且没有经验人才加入会导致公司技术更新缓慢、影响公司的技术发展；当然，毕业生也有好处：白纸一张，可塑性强，比较认同并容易融入企业文化。

2、从个人角度，运维工程师技术含量及要求会越来越高，同时也是对公司应用、架构最了解最熟悉的人、越来越得到重视。

3、网站运维将成为一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，给大家提供一个很好的个人能力与技术广度的发展空间。

4、运维工作的相关经验将会变得非常重要，而且也将成为个人的核心竞争力，具备很好的各层面问题的解决能力及方案提供、全局思考能力等。

5、特长发控和兴趣的培养；由于运维岗位所接触的知识面非常广阔，更容易培养或发挥出个人某些方面的特长或爱好，如内核、网络、开发、数据库等方面，可以做得非常深入精通、成为这方面的专家。

6、如果真要以后不想做运维了，转到其它岗位也比较容易，不会有太大的局限性。当然了，你得真正用心去做。

7、技术发展方向、网站/系统架构师。

数字化开始从抽象化、标准化走向智能化

2020 给全民普及了什么是线上化、数字化、智能化，也加速了企业的数字化转型。“全数字化”时代，已经不仅仅是简单粗放的数据采集、映射、抽象。 数字化开始迈入高级阶段——数据驱动的智能化 ：基于云管端 + AIoT 等为代表的新技术群落开始大量涌现，数智化企业思考的核心问题转向了如何以客户运营为核心，通过智能化手段提高客户全生命周期的体验。

作为物联网大数据行业的排头兵， 深圳数联天下智能 科技 有限公司 （以下简称数联天下）倾力打造的 C-Life 大数据综合计算服务平台，致力于为个人、行业、政府提供全周期、全链条、全维度、全方位的专业级运营顾问式服务。依托着公司强大的研发投入与技术实力，数联天下在智慧养老、智慧 健康 校园、智慧美业、智慧家庭、智慧酒店、智慧农业、智慧水生态等多个智慧领域，打造了一批又一批的标杆示范项目。

企业的敏捷性、适应性、反脆弱性，决定其在这场数字化颠覆中的胜与负

在交付各个领域的智慧项目过程当中，数联天下的研发部门逐渐发现问题：研发团队面对的是一个更加不确定、个性化、碎片化的市场需求。行业项目虽然存在着一定的通用性，但也因地制宜的存在大量定制化需求。如何让个性化与规模化齐头并进？多变的客户需求带动了研发组织开展与业务相适应的调整。 通过研发流程数字化提升研发流程的敏捷性、适应性、反脆弱性，数联天下开启了研发提效之路 。

数联天下研发团队和我们分享道：“客户项目周期紧张，需求变化比较频繁，开发团队需要在短时间内完成软件开发并发布上线。而在之前的研发流程当中：发布流程长，审批环节多，发布节奏缓慢，开发运维之间没有良好协作来提升发布效率。所以亟需打破跨部门之间的壁垒，减少开发、测试、运维之间的沟通环节、沟通成本。DevOps 是我们在较短开发周期内开发高质量软件的首选方法，希望通过使用 DevOps 平台 —— CODING 来提升客户满意度。”

区别于之前通过多个工具自建研发流程，数联天下团队首先基于 CODING 的持续集成、制品库、持续部署逐步提升交付带宽，再将项目管理、研发数据管理等流程统一至 CODING ，渐进式实现研发流程从需求提出到应用部署的价值交付，从而让研发团队各个角色基于统一平台通力协作，按期保质交付项目。

持续交付驱动业务加速

在使用 CODING 的过程中，数联天下研发团队遵循着循序渐进的路线。首先基于 CODING 持续集成、制品库、持续部署建立持续交付流水线。区别于自建 Jenkins 与 Nexus， CODING 的持续集成与制品库开箱即用 ，研发团队通过持续集成构建好的 Docker 镜像可以直接推送到 CODING 制品库中，再通过持续部署拉取指定版本镜像进行部署。

CODING 持续集成在构建脚本语法上全面兼容 Jenkins，支持数联天下无缝地迁移 Jenkins 的构建到 CODING 中。并且支持 Docker 镜像的构建，在基础功能上满足了研发团队对构建制品的迁移需求。

在使用上，CODING 比自建 Jenkins 要方便许多，打开浏览器就可以使用，不需要繁琐的机器配置、构建环境搭建、软件插件安装。而且 CODING 提供了多地域境内外构建节点，并优化国内访问海外主流镜像链路，支持构建任务中开启缓存，大大提升了构建速度。在构建资源的灵活性上，既支持数联天下使用 CODING 云主机进行构建，也支持数联天下将使用中的腾讯云机器设置为构建资源。

在使用 CODING 制品库之前，数联天下团队基于开源项目自建制品库，在使用自建私服制品库常常遇到性能问题或易用性问题，比如一上传大容量的 Docker 镜像时，自建的制品库就常常服务不可用，导致后续一系列的版本发布受阻，使用 CODING 后这类问题就迎刃而解了。 CODING 制品库是专为生产环境打造的企业级制品库 ，无论是制品库的容量、分发效率都经过产品团队精心优化。数联天下团队将所有制品推送至 CODING 制品库，利用 CODING 制品库提供的版本策略、权限控制、安全扫描等能力对制品进行了规范管理。

不仅仅是 Docker，CODING 制品库提供了十多种主流制品类型，包括 Helm、通用文件、npm、Maven、PyPI 等等，可以支持研发团队多样化制品托管需求。同时制品库提供的精细化的权限设置，支持每个制品库设置项目内、团队内、公开的开放范围，针对多团队并行开发的场景，数联天下可以轻松地将通用组件设置为团队内开放，将项目独有的制品设置为项目内可见，既能加速公共制品在企业研发内部的共享与流动，也能确保项目独有制品的权限安全。

对于频繁进行商业交付的研发团队，安全也是商业客户关心问题之一。CODING 制品库除了解决数联天下团队的制品托管问题，还对制品的安全质量进行了规范。通过制品扫描设置质量红线标准，杜绝问题组件发布至生产环境，扫描方案还提供了详细扫描记录和缺陷统计，方便研发团队快速修复。这在一定程度上提高了制品的安全性，减少了应用在生产环境出现的安全漏洞问题。

接下来就是打通持续交付的最后一环——持续部署。通过持续部署，研发团队可以自动、频繁地将软件部署到各种生产环境，使软件产品能够快速地交付使用。

1 清晰灵活的流程编排

数联天下运维团队首先根据测试流程、上线流程以及部署环境规划好每个应用的 部署流程 。针对开发环境、测试环境、类生产环境、生产环境分别创建不同的流程分支。基于 CODING 持续部署，可以快速地编排出串行或者并行的部署流程：例如针对类生产与生产环境，必须要在类生产的集成测试（自动化+人工）通过之后，才可以进入生产环境发布；而多地域的生产环境发布，就可以并行部署，提高效率。

基于 CODING 持续部署 清晰灵活的流程编排，应用所有的部署分支流程一目了然。

2 人工审批加上自动通知机制

针对过去运维发布过程中的多环节、多审批、多等待的情况，数联天下团队根据发布流程的级别差异将测试、产品经理等角色加入审批环节，配合自动化部署过程和通知机制，解决了从前需要人工反复确认部署环节的问题；也解决了从前开发人员只能等待运维人员定时部署版本的难题，开发和运维人员都可以随时随地按需部署应用。

每个环节的通知除了支持常见的站内通知、企业微信、钉钉、Bearychat 等方式，还支持团队通过 Webhook 的方式接入企业使用的其它协作工具，满足团队的个性化通知需求。

3 规范的制品版本规则

在项目紧张的开发周期当中，数联天下的制品构建地十分频繁，制品数量也在急剧增长，其中包含了开发自测的 snapshot 版本和正式转测的版本。如何确保测试环境、生产环境等能够始终选择主干发布的稳定版本，避免因为手误选到开发自测版本？通过在持续部署中的制品分支策略制定所选制品的规则，杜绝以往人工选择临时分支版本导致的错误情况。

4 统一的部署控制台

在数联天下团队的日常应用部署管理过程当中，CODING 持续部署提供了以应用为视角的控制台。运维人员可以对所有应用的配置信息、基础设施、资源分配、部署流程进行全面管理，无需在各个项目视图之中来回切换。这对于需要面对繁多项目的数联天下研发团队来说， 统一的部署控制台面板，大大提升了应用部署管理效率。

在应用部署完成后，就可以在 Kubernetes 集群面板中方便地检查部署好的资源，包括集群内资源的工作负载情况。一气呵成的部署 *** 作帮助运维或者开发人员一站式完成部署资源准备、部署流程编排、应用部署、部署后的检查工作。

紧接着研发团队将代码管理、项目管理迁移至 CODING 的代码托管、项目协同中。告别了过去的 SVN 代码管理，基于 CODING 代码托管进行 Git 式开发，基于代码扫描与 Code Review 建立研发质量的基线。切换到项目协同进行项目管理后， 真正打通了从需求->代码->制品->应用的全部链路 ，数联天下研发团队基于统一云平台真正实现端到端的价值交付。和以前基于多个工具自建研发平台的方式对比，统一研发管理平台带来的好处有：

基于 CODING 的 DevOps 实践，数联天下的交付带宽达到了较大提升。DevOps 实践给数联天下的研发团队带来的不仅仅是流程上、工具上的改变，也进一步加深了团队的业务共识。所有角色都坐在了一起：测试、运维、开发、产品、项目管理等，研究如何基于统一平台通力协作，按期保质地交付项目，服务好客户。

数据已经成为生产的要素之一

研发数字化不仅仅是自动化流程的搭建，更重要的是在数字化落地过程当中，如何将有机串联的研发环节发挥出 1 + 1 > 2 的效果？如何让研发数据服务于研发？

目前数联天下的研发团队已经将研发全流程切换到 CODING，慢慢积累的研发数据也给研发管理带来了新的指引。通过效能度量，可以清晰分析成员工作负载；通过仪表盘可以清晰看到代码提交数、事项完成数、构建次数、发布次数等等多个维度的数据展示。这些数据也将支撑着研发团队快速地调整和检视以适应更加多变的未来。

数联天下研发团队负责人告诉我们：“最开始选择 CODING，因为 CODING 持续集成全面兼容 Jenkins 的持续集成服务，支持 Java、Python、Nodejs 等所有主流语言，并且支持 Docker 镜像的构建。这与公司现有的发布方式，架构体系相吻合。在使用了一段时间后，不仅仅是持续集成，包括 CODING 制品库、持续部署在内的 DevOps 工具给我们的研发流程带来不少提升，也期待 CODING 能够在研发工具链上给我们带来更多惊喜。”

在全面了解数联天下的 DevOps 实施路径之后，我们也发现企业的研发变革不是一蹴而就的，需要从流程上环环打通， 选择一个迁移成本低、使用门槛低、功能灵活的一站式研发管理工具，能够让变革事半功倍。

我们欣喜地看到，数联天下一直走在提升内部效率的道路上，这家志在提升各行业数智化水平的企业全然拥抱了研发数字化，我们期待 C-Life 凭借着变革初心与极速交付能力，逐步成为智慧生活的强有力支撑平台。在这场数字化颠覆中，CODING 也会坚定地与研发团队站在一起，依托 DevOps、云原生、敏捷等研发利器，帮助各行各业改进、提升并创新。

专升本快速报名和免费咨询：>编程语言Toit开源了！

Toit 是一种面向对象的物联网编程语言，在 IoT设备上能够实现秒级代码部署（注：如果使用C语言，一个简单的代码更改需要几分钟才能重新部署）；同时，Toit也是一种现代的、内存安全的编程语言，集成了先进的编辑器功能，如语法高亮、goto-definitions 、代码自动补全等等。

Toit 编程语言具备以下特征：

Toit的出现是因为有一群软件工程师对IoT开发的现状感到不满，凭借着在Google为Flutter构建V8 JavaScript 引擎和Dart语言的丰富经验，他们开始自己构建适用于IoT的最佳平台。也正是在平台构建过程中，他们意识到必须有一种高效的编程语言来满足物联网的需求。最开始，他们尝试使用了Python和JavaScript，但在微控制器上，这两种语言的速度都不够快。

为了解决性能和健壮性问题，Toit团队开始研究Toit语言，经过测试发现，Toit在 ESP32 上的执行代码速度比 MicroPython 快 30 倍以上，同时学习门槛也很低，Python开发人员在几小时内就可以学会它。

为什么会选择开源Toit？Toit团队表示：“从一开始，我们就明确知道Toit肯定是会在某个时刻开源的，因为所有主流的编程语言都是开源的。开源可以获得充满活力的生态系统，编程语言才能被大规模采用。经过多次迭代和实际环境的应用，Toit语言已经成为微控制器编写强大软件的利器，我们希望更多开发者能够从中受益，因此选择将它开源出来。”
链接：>