标签：系统
来个接力，谈谈自己的看法，班门弄斧，拋磚引玉，期待更多小伙伴的分享。
系统即服务
大到传统的物流系统，小到一个部门wiki系统，归根到底都是需要人来使用的，人使用的目的是满足某种需求，系统为用户的需求而服务。
试想一个没有服务功能的IT系统，哪怕代码算法写的再牛逼，编程语言使用世界上最好的语言PHP，数据库有全宇宙最牛逼的oracle，存储用的是全银河系最牛逼的EMC设备，不能给用户提供可靠稳定安全的服务，它就只不过是一堆成本昂贵，毫无价值的垃圾。
服务的方向就是，提升用户使用和服务支持的性价比。
无论是QQ还是微信，抽象到用户服务层面都是用最具性价比的方案来满足用户的生理以上的需求（毕竟微信不能直接当饭吃），比如安全，沟通，归属，炫耀，装逼等需求，同理一个无论是从用户处赚钱的（比如游戏，比如各种钻，比如各种会员），还是拿用户来赚钱的IT或业务系统，比如各种广告，也是在直接或间接为用户或客户提供服务来实现自身的价值。
所谓系统全局把控和设计，个人认为就是大到整个业务系统，小到一个单个服务系统，如何才能更有性价比（成本低），更灵活（便于应对变化），更可靠（高可用持续服务）地为用户服务，简而言之，就是一个系统在设计之初需要考虑哪些因素，这些因素都是功能以外必须考虑到的。
系统到服务
系统到服务的过程，就是系统运维过程，服务管理或者说是技术运营的过程。系统设计当初就要考虑到后期提供服务的特性需求，比如制造汽车时就要考虑到轮胎更换的便利性，恶劣天气下的可靠性，在设计业务系统就应该考虑到一个系统的可运维性，是否支持模块化横向扩展，是否支持高可用，是否支持集群管理，是否有良好的容错和除错能力，支持极端网络或复杂情况下的稳定性，是否对系统服务进行分级（方便管理和取舍）支持灰度关闭某些次要功能，业务和运行日志是否详尽方便排查问题等等。
系统全局把控和设计，需要我们站在规划城市的高度去搬砖。
由于各方面原因，开发人员经常不会考虑自己写的代码会对线上运营环境造成什么影响。开发人员对配置或环境进行修改之后，没有及时与运营人员沟通，运营环境受到影响。开发是由功能性需求（通常与业务需求直接相关）驱动的。运营是由非功能性需求（例如可获得性、可靠性、性能等）驱动的。变更规模越大，风险也越大，因为其中涉及的区域越多。由于运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了开发人员将特***付给用户使用的速度。运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程。开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。
搬砖的高度去搬砖最后就是一对砖头，建大楼的高度去建楼最后就是一大堆烂尾楼，规划城市的高度去搬砖，虽然还在搬砖说不定有一天可能就是一座城市。现在可能我们开发的就是没几个用户的小系统，如果只是抱着满足产品的需求去做，那就祈求这个产品不要火，火了可能也会因为恶劣的服务体验早早死掉，试想如果微信天天崩溃退出，支付不成功，或者支付不到账，再牛逼的产品也经不起服务体验差的折腾吧。
一个业务系统在整个研发流程中分为运营前和运营后两个阶段，这两个阶段虽然有明确的划分，事实上也是有关联的，这也是devops理念的一部分。运营前需要关注的是高效率和高响应能力的软件研发管理方法，比如敏捷开发，以及版本管理，质量保证，运营中需要关注的是安全，高可用和负载均衡，问题和事件管理，用户体验反馈从而促进运营前的迭代。
服务与管理
提升系统全局把控和设计能力的前提，需要了解需要把控什么，需要设计什么？
这里从一个运维的角度来谈下，在运营前的研发阶段，我们除了满足产品需求后，还需要关注些什么？毫无疑问，这些也是运营过程必须要关注的。
服务最重要的是什么，稳定，稳定，稳定，重要的事说三遍。
如何保证服务能够稳定可用呢？影响稳定的因素就是各种变更，功能变更，配置变更，环境变更（网络变差了，磁盘满了，服务器挂了），有些事主动的变更，有些是被动的变更，应对这么多变更，是不是应该有一套体系来保证服务的稳定可用呢。
当然，这一切都不是我的总结，事实上已经大牛给我们总结好了，一切业务系统都是服务，IT服务管理最知名的理论莫过于ITSM，ITSM是基于ITIL，一套从计划、研发、实施到运维的标准方法。
ITSM的核心思想是，IT组织，不管它是企业内部的还是外部的，都是IT服务提供者，其主要工作就是提供低成本、高质量的IT服务。而IT服务的质量和成本则需从IT服务的客户(购买IT服务的)和用户(使用IT服务的)方加以判断。ITSM也是一种以服务为中心的IT管理，以流程为中心，从复杂的IT管理活动中梳理出那些核心的流程，比如事故管理、问题管理和配置管理，将这些流程规范化、标准化，明确定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标、有关人员的责权利，以及各个流程之间的关系。
从中我们可以看到，ITSM的三个目标：
以用户为中心提供服务（用户就是上帝，对于用户体验的抱怨要敏感，及时跟踪）；
提供高质量、低成本的服务（用最少的机器，写最少的代码，用最差的服务器，服务最多的用户）；
提供的服务是可准确衡量的（业务的可监控性，日志，日志，日志，重要的事情说三遍）。
ITSM的三大核心：技术，流程，人员，最终都是服务于业务。
IT服务整个运营流程需要关注的：
从运维的角度，难免以偏概全，ITSM说了业务是核心，流程是关键，整体架构简单明了后，至于用什么技术实现也很重要，至于什么时候该扩容，什么时候该拆分，什么时候该加缓存，这就是具体的技术实现了，ITSM就管不着了，希望开发同学能多多从开发的角度来谈谈这个话题。
跪求。
学习与提升
多刷知乎，少刷微博
多关注行业牛人，少咬狗。
一个人靠谱没用，得团队靠谱。
工具能做的事就不要浪费人的精力了。
要有女朋友，这样身心健康，才能全身心投入工作。
了解金字塔思维（对应线性思维）和系统化思维（对应单点思维）。
标签：系统
原文地址：http://liuqunying.blog.51cto.com/3984207/1685407
