服务水平管理函数的“解析解”与“数值解”

就爱抬杠

服务水平协议(SLA)已经成为IT服务管理的共识，要搞SLA，应当满足“用户能理解，IT可计算”的要求。进一步来说，所谓的SLA，输出就是业务部门所要求的服务水平，输入则无论是硬件、软件、网络还是服务最终都可以归结为钱的问题，而且钱无论投在哪个方面都是一样的，研发上多投入一千万能解决的问题，就没有必要在设备上多投入一个亿。
  {- N) r* N6 O& I3 Z
我们可以给出一个服务水平管理函数Y=F1(X)。其中，X代表资金投入，Y代表服务水平。当然，Y未必是单一指标，但即便是多种指标，也可以把指标的组合当做一个变量。
0 g0 f2 w( X+ g% r; b
$ Y7 L, S5 C/ J现在的问题是，这个方程怎么解？

6 x$ B0 N- s( T, q首先可以找出那些运维管理基础设施管的东西，例如主机的内存、CPU指标等，可以把它们叫做KPI，网络有网络的KPI，主机有主机的KPI, 甚至维保服务、支持服务都可以有自己的KPI。这些KPI是IT自身可以衡量或者说可以掌控的东西，更干脆点说，就是可以转嫁出去的东西。假如IT需要实现这样的KPI，就可以通过签署合同从外部购买设备或者购买服务，这些KPI都可以在这些合同中直接体现。
8 j4 }  O0 m8 w$ c5 w( D
/ }* c* a4 p5 c! Q  B+ }假如把KPI的集合也作为一个函数，Z=F2(X),这个函数的解是不难求得的。

) {; `- T: n4 E再下一步，在IT和业务的中间，需要一个服务层作为媒介。这个媒介可以类比为Windows的API，对用户来说屏蔽掉底层信息，对硬件来说也不用管用户到底要干什么，只要提供好API需要的资源和计算就可以了。服务也是如此，对用户来说，需要把自己真正关心的需求映射到各种服务上；对IT来说，则需要专心致志于对各种服务提供支持。
) P! `0 U" B9 y) z
0 j- u0 }9 `: b; y. k/ f& `) d1 e, K在这里，对IT来说就存在很大的问题了。对于某一服务来说，基础设施的构成五花八门，主机、数据库、网络等等都有很多种，单就某一项来说还好计算，但要计算所有这些项的组合就很困难了。例如就某一服务来说，可以有100万的投入，要降低CPU使用率，可以用加CPU的办法，但要减少某一服务的响应时间，究竟这个钱是投在开发上，还是加块CPU板，还是加内存、拓宽网络，抑或兼而有之？倒过来，想提高一点服务水平，到底需要多少钱？假如我们把这个函数叫做W=F3(X),这个函数的解就很难求了。
7 Q( _: V$ ^$ @& A3 U
0 K: P! r7 O, E4 z& ]( _6 i5 ?6 k目前解决这个问题有几种思路。

$ j; J7 l  Q3 ~! c9 t其一是摩根大通的做法，有点像西南航空买飞机，所有东西只有一种型号，但这个一般公司做不来。首先应用没那么简单，其次，招标采购等等流程，根本也不允许这样做。
6 j: ]$ ^, \( c# g/ ^
其二，搞云计算，基础设施标准化，虚拟化。用云计算平台虚拟出资源的“单元”来，所有特性都被平台屏蔽。买各种型号，不同性能的东西，都能对应出所提供的虚拟“单元”，然后再考虑服务所需要的虚拟“单元”数量，以此计算出服务所需要的资源投入。
$ A' I% p7 T3 Y
( x7 \5 P( |$ J2 O5 r& W6 I! s但虚拟化也不是那么容易做的，做一部分容易，把提供服务的全部基础架构都虚拟化可就没那么容易了。
, |7 n6 @3 h) I# `4 T
假如我们把服务管理函数比作一个偏微分方程，众所周知求偏微分方程的解析解首先靠运气，其次才是靠技术。以上两种方案相当于固定一些变量为常量，把偏微分方程简化为微分方程。
9 v) ~; z7 E+ j7 I& Q
另外一种思路是什么？不求解析解了，求数值解！

当年学的计算数学现在全都忘了，只记得第一次见到那种暴力破解美学时的震撼，原来数学还可以这么玩，原来初中学几何时的证什么证，直接尺子一量不就知道这两条边相等了吗之类的想法还真能成为一门学问......

- v, [- M) [) |( z: V2 P计算机学习语言就是这么干的，学什么语法，搞什么规则，直接把网页全下载下来灌进语料库算概率......

数值解永远是局部的，我们只处理少量的问题：

$ s1 F* F0 X# F2 p+ ~: U( s$ X9 g  |如果假定相同的事故会导致相同的事故后果（或者说事故等级），这个假定当然需要一定的冗余度，也有很多例外，但在大数法则下还是成立的；我们又试图用标签来区分不同的事故等级；更重要的是这里又做了一个假定，暂且不去区分导致相同事故等级的不同种类的事故；我们只想算出可能导致某个级别事故的所含标签（组）的概率，而且还可以不断对标签的定义及设置进行优化，在这些假定前提下，用一段时间收集数据，建立一个比较好的模型是完全可能的。

下一步就可以逐渐区分相同事故等级下不同的事故，通过不同事故的出现概率、处理流程和处理时间的计算，就可以得出服务在生命周期内中断的概率及恢复时间的预测，以及要想减少某些事故乃至近乎完全消除某些事故的影响（例如可以通过备份实现）所需要投入的资源。

我们无法得出平滑的解析解，但我们可以得到断续的数值解。

假如十八

看到解析解三个字泪流满面地走过

就爱抬杠

假如十八 发表于 2012-7-3 17:01
: o1 F* x! f! [( c% Y看到解析解三个字泪流满面地走过

* p1 s: Y* z4 J0 G' j7 z呵呵。

假如十八

就爱抬杠 发表于 2012-7-3 17:14
呵呵。

读书时候，老板笑眯眯的跟我说，做个仿真算了吧？

" M3 s+ t; S0 R& H不行，不行，我要搞定解析解！

' N1 T. ]5 U6 D6 r5 ~. n: _* p一年之后。。。老板，我还是做仿真把。。。

就爱抬杠

假如十八 发表于 2012-7-3 17:22
3 ~' y2 \' O3 K3 k  h+ f. q4 |读书时候，老板笑眯眯的跟我说，做个仿真算了吧？
) _/ [0 Y9 y1 c4 [
( C" Y  C$ h; X/ Z2 N不行，不行，我要搞定解析解！

那只能说运气不好。我是学自动化的，搞工的有数值解就可以了