请选择 进入手机版 | 继续访问电脑版

IT运维管理,ITIL,ITSS,ITSM,ISO20000-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

艾拓先锋
搜索
查看: 354|回复: 0

DevOps老手如何同时抓好运维与开发?

[复制链接]
来自- 广东广州

参加活动:0

组织活动:12

发表于 2018-8-27 15:35:54 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 monicazhang 于 2018-8-27 15:53 编辑 % }0 G% v9 c+ P4 Z% _4 Q# B
& j7 h7 z0 U1 g5 Z) T$ \# }* i
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。
* J- o+ I* F' d3 {, q

; N1 v9 u# ]5 ?1 B* m- X3 R
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:DevOps

0 o1 _) j5 m" g% l8 A3 @% ?; I
1.png

& x8 K/ N2 [! O" j, u
DevOps
/ F* ~* _8 m! j$ \
1 r% ^/ [; j- Q) I
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。
+ ^- Z9 C4 `: A, E0 Z
) z# v+ _$ X0 ?0 e( i/ o6 i
DevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。

$ ~  K% A& ?+ \5 \/ |
8 x: }4 e# Q1 m+ A( h1 H
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。

3 w1 {& \1 Y. n. X$ ]
( U. G5 j5 Z" Q9 G& N# W

一、前言

9 M- X9 T% r9 ~$ c# j8 D
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。
) J* A) d# g! ?% _* S0 @

  J6 O5 H5 E! N
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”
/ ]+ l  t1 K5 ~7 u3 J

9 e: I: L6 E) X' t  I( u
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。

$ h- y$ F/ _+ j

& w- a3 p( J7 ?+ Z  U  s
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。
# S; {8 X- b6 x; @
0 k4 f8 Y! U8 y/ V$ H
本文,我将自己关于这些问题的思考分享给大家。

) ]* O& ]. b- j
7 r( {' M7 @4 W- Y

1 _8 y5 ]9 I1 ?) Q; P+ P

二、什么样的平台是好的运维平台?

/ Y" _. u( Z9 b9 h
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?
8 X8 ~% d# \- M) x0 O5 F" R
3 ~$ e( ^8 z1 u) M' J( ~0 Z  L
如果让我们来从头设计一个平台,我们应该如何去考量?
  n5 {" T8 I( c' E: F# E2 X5 h

& N8 L. N3 Q" A3 X. }* D
1、效率 & 成本的均衡
- e) x8 g, f* K

& A4 }9 [" o8 N, |, J8 b运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。
$ b! y  P' Q& r- u; z- H

' O9 Q, V+ W0 s% K2 s" b: e- f至于如何量化比较,就因系统而异了。

9 F+ G* }  u# ~% Y0 g$ B0 h
  g+ x4 M8 p2 V
2、体验 & 人性化! x* m) w: T1 [" D
* f& m8 e% E  E
) u; q, m, P! `% @0 ]5 \9 F
为什么我要把体验放在第二位?
5 P' V# i0 D; C7 `9 @' U3 X4 ]  j
" M! E9 v/ @, f/ w" u. z2 @; H$ z3 I, Q
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。
+ T+ A6 p6 O( I  C

/ I0 \7 n! B* W0 s, y; P我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。

9 D( o! |1 N9 Q  _/ m
- N7 h5 c( G' D! B. F
3、优秀的系统架构

- r7 G" X. q% v( _4 {. u

% {7 U  ~* ^# R/ ^" b$ T9 f( I6 U8 p在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:

! d$ H$ n, F9 L" B( z

+ L5 l; T! h2 x
  • 稳定性:负载均衡、多活等。; C& }/ f) G1 U
    $ G7 k6 }. j7 c$ K. B" }
6 v4 A! f" V5 z2 C
) R7 b+ B1 o! P2 r6 {
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。, y. C. w: z" h& v  b* d1 Q: C4 P; a
; w: H8 Z" n( W* V; V

- C, u8 C8 Y* K: ?& B+ n7 w
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。
    7 B( G$ b, u+ \5 s

2 R' ~1 O& L/ [1 I8 s# ^+ ~5 L$ ^$ I/ q( C$ S9 n4 E
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。
    ( r2 Z1 U4 }; e& t) ^* m+ z/ T; _
( o4 ^& W8 [+ h, q. }- }
+ B9 B/ N% `, |" d8 L. l1 W

( T) V4 J( ^, h7 |7 p
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。
    5 T. y. D. u3 d$ p

5 ^3 C: U% C- h  L5 H- o
" k. Q$ P/ F" n5 M6 u, e" _# c& i  W0 T! m
* z# j0 U4 q1 K( y( m5 V3 U
、如何运维自己开发的平台?- G" a% g, J' G: s1 g* x
2 k0 @+ ^* x7 E+ y8 a, n( e8 W
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?

: h5 J7 ^9 l, C8 `) h

' k$ z" t" Q+ l( \: I# C0 B; a运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。
0 |' T! \! ]5 o5 u) _: C
, b9 [/ U1 q) O7 l
用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。
' N* s  z& \  f+ ^* m4 g8 h1 n
8 r5 l* G; \1 Q4 x0 Y
1、架构上的稳定性
2 d4 i- u& v. x! b/ m! B
* t' K" {( b% D+ m! q

0 F8 V4 S2 j/ w; E/ [, a% R; }
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。

3 p6 g- R4 x- G% Y  {) Z- f" F; K

* z0 k3 r" W" m% ^
2、快速地发现问题6 ]3 a- d$ _. I9 l7 `
. h4 {+ l. k) F/ x4 E# m$ r/ V

! n7 r5 E( [) S* u' H
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。
$ d8 N, F9 F+ v" u  n6 [

5 _) T9 Y+ a5 {9 h2 d还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。
1 w& K8 R$ q) Q# A9 D# k- e
3 x7 O1 ]! @4 W+ T6 C6 m
3、应急预案&演练. `0 |+ f9 I6 A$ g8 I' Q
$ r* |. c% M2 E/ n

7 ^- S8 x2 W8 v1 V9 L
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。
9 ]2 o1 Q; T+ y: H
5 `% B' M0 h( f/ Y4 w' _
因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。

* l0 ~1 o2 T8 X+ R8 |* F- a

2 B* Q7 H: s2 y/ E0 ~
4、自我保护3 I+ l5 U5 i. ^3 r% w2 M3 \0 D

3 A5 G8 y; [( F6 r6 C# z% v3 R" B' C

1 p- e. z8 i* I* T7 N$ s
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:

1 w! }* `$ H. b( n
( H. B. W% \+ L
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。  {0 F$ }$ l2 Q
    4 N' q0 ]( G; V1 D" I' V3 J- N

% @' z7 t* D+ V0 q" g3 L  [
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。
    # J, H7 ^+ L- ^, D, j; V
      G8 R8 G* c9 V0 T6 `2 l8 {% c5 q

& }8 q& Z& x; r/ |

3 Y* N% z3 U3 S6 ^& v4 ~( |
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。( \5 c. M- v# w
    / x- a" x2 F% w+ F: g

  M8 _- ?; y0 V4 ?) D7 x' e7 B: l, s; D/ [- X8 V  `
& Y! C6 P) i9 l. R* H; d1 J
5、容量规划
9 j* d. ?; t8 Z) {/ g# u: ~

( }" o4 T6 U8 ~
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。DevOps
2 Y3 I4 Q& i) d0 H  Y; V( m' b
" O- I) u& g2 p8 M; p' [2 ?
笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。

2 {' R. g4 @/ W  p  H$ \# p

' I; D: F: r' l9 o0 k7 V' h, ]
6、变更管理8 w' X" ]1 T" ~7 D  u5 O# V+ \

8 K' A9 W/ b/ z2 U8 E9 e
' j" `' i8 w) A* F0 j
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:

+ Y6 h5 [9 {; v. s( t" B- T
2 C' q8 K- T9 H5 }- a  w
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。: s5 z0 T7 U0 X2 D3 O

    8 t9 o. }# V9 J8 l) J( {- y+ G
6 v! T7 q6 o$ l- ^# n
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。5 e  M$ j$ ~& p' k; S  j

    . W' F; e% a! g' S& W" _7 Q/ |  [

" N& ]" u7 p$ r$ j7 N7 @  l8 n

0 Q2 x: d) v1 w# M

  x2 Z. O  G. ~) n1 Q! H
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。
    7 L9 i5 P! A* l# a. x. V4 P

    % u5 g/ m2 e& I4 q

, K8 h, {/ p) D, _+ C2 a) r
; X: p+ `! i# H

3 b) ~/ c% `1 F+ }) s! N- ~

四、除了开发与运维,我们还要做什么?

0 i, I7 k; h1 l3 p; K# P


" v: I+ D0 W2 U( B) L# T
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。

3 s) W) a/ f" a8 o0 _3 c

/ @  r1 C& T0 N4 u$ t因此,我们要考量的,还有产品和需求层面的东西:

( O& ]' d0 P4 l9 s* }; Q

3 Z9 |; t; N  l' C6 X
1、需求管理0 h" M# O9 p/ Y3 G1 B; u3 W
; b! y& \' y5 ^" L8 H4 u4 {
3 t$ {0 u, w9 M6 l) h; r7 l
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。
$ p/ Y' w& E: J! E: \, V( J
. X6 x: v- y$ n; A( H- K
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。
    0 r+ T5 Q* D. w6 K! r
# `$ I( E# p1 f0 K$ t
& o' v$ T; N% e4 S. C6 p
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。
      V1 B2 R' i1 ~2 [, i' D7 `
# {7 I( ^2 }4 e2 H) U
  • 对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。! T8 F( ^' }$ I* {7 i* c: ~" r
    ' i8 b% U) v1 G# E
; j! t+ O+ H2 S4 @- H

. F9 i( T1 A# l9 i8 ^  }3 e
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。4 h  G0 Q( }1 v* z: N
    & v% e7 \0 A5 Y( P- X2 b

7 W; k1 H* |3 A2 I2 \& J
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。+ y3 \. v# A0 [$ J1 R# }3 e
    4 y6 L( }* C" j6 w
1 a! z4 g8 k  \- @' E0 L

2 r8 u1 F* v* }) g1 X, S$ J2 R  W
  • 因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。
    . ~- C( H+ u$ i* o( Z% l. [
    7 j3 a) M+ Z$ D! M
" I8 z. U/ o5 O4 M
; D$ U, v! @# s- V% R  R0 B
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。

      ?/ W% h+ z5 D. o7 c  q
    ' j' p& Q0 p' Z. X7 F0 o2 a* ^

6 _$ z, p# C2 D
2、量化
6 `1 C3 a1 K0 s5 V% j+ q+ c
; O6 |( |9 W; k: r4 I/ }( k
4 I7 }8 Y$ I0 M5 j0 S
If You Can’t Measure It,You Can’t Improve It。量化是优化的前提。
1 g/ r, S) k% `: I* k6 _

# o' u/ A' q) v6 ~量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。
$ \6 q/ ?% }, ]- ~. g% T3 h' B
4 |4 r* R# \- {
3、制定SLA
; j& k: I9 q/ a: `/ \# }6 H+ o3 M/ p2 W: v- g8 F; ]

' w: O. C1 Y( h& \/ o3 a简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。
+ f9 Z  `& x0 C2 a" x5 a4 q
3 G1 d" `# S$ G! X) f3 W
一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。

/ o0 u  h$ M9 b$ j, l

" Y8 _( a" j6 t; u1 [4 C2 ?) @( S
6 L" I# [, q' u( D% e2 j# W) k9 a

五、除了做这些,我们还要思考什么?


  }. q, C8 @2 D) L. K% Z! _


6 O# j/ E% I6 ]4 o5 o
1、制定规范,并让规范在平台落地
5 X7 i+ {+ ?9 N8 }2 j6 u
* J' G; E- \5 f8 a* s* O6 Z
5 E! m4 `% L' v5 X8 x. d
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。
7 v/ S* Y& m$ ^+ Q& W8 x

1 ^: w3 ?+ H% [0 ^1 N; [规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。
/ a' X: V. c/ Y1 h6 a6 u; ^
6 g( v! F$ [% V$ b* c& l
我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。

  N! F, W- E& O% w/ X
: P1 Z1 X' M1 f
具体的实施方式可以考虑限制和引导两种手段:

3 X+ ~. I# ~7 S9 [3 Y
: G# h! y) [3 d$ k
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。
    1 ?/ w4 @  a6 U

, y$ J2 ~9 U; \/ _. g

$ s* Q( C. E9 m$ M: K/ y+ Z! g- D
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。
    0 c0 B# r( B. _, F, j! n( u. @8 U- A

& N9 K5 \; z+ a) F
2、协调开发与答疑* z: }+ |" z; `  o

$ Q5 M# h, f2 z! Q# o( z: g

0 o! T5 v+ \) k3 x运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。

, z) d; p! h5 D" H% O+ B
3 |0 n' B1 {2 k
日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。

5 ~7 P, m+ l- |! m% T0 a/ K

8 K( x; m7 B' Y1 a! ?7 N
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。

$ W  _) _, M9 q" `7 o7 h
6 ^2 m8 v2 U: |; ~& a9 D1 b& G
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:
8 ]8 J  N2 f2 b: G* [6 P) ~' w0 z

; V1 _3 u$ P, q5 ^
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;
    ! ~1 G1 b; A& e: @' e" u: C) w
    . C& ?0 e( x9 @0 {

7 y; K6 r$ k- a6 X/ a
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。
    ; Q7 i1 z7 s' h$ O2 r
& K. l3 L8 \$ Z
我们也要同时思考如何与这类用户说明,提高小白用户的体验。
4 U" t& Q6 u4 D$ I7 H4 a# x

4 k, m  N8 j' [7 a+ u( B因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。
& a  ~+ N! C* B) B+ e+ K$ D$ |
7 @2 F  d+ @# i
3 ~) ?7 u1 {7 a

六、后记

- `$ R6 \" K3 ~% {9 \6 f
  Z. ~# o6 g9 ]9 q
时光荏苒,倏忽之间,我已从一个小小的实习生,成长到现在勉强可以独当一面的样子。这些年来,我一直在自动化运维平台开发领域耕耘。从刚开始重构服务树、权限系统模型、堡垒机登录;到后来的流量调度、监控系统报警与存储的深度建设,有很多个人的感悟与成长,梳理了一下,分享给大家。

! T0 ]. s# Z- t9 n9 I/ ]

1 m' \- o  ], ]" B6 r; L- M最后附上笔者思考本文时的脑图:
3 Q$ c6 l$ l) h/ Q9 d

; s0 B1 b. t* i3 i) q1 Y
2.png
- J/ A' y- {4 K3 Z0 N" T

5 A; r/ V& M. y" |

$ v; \) p# v& @
0 [6 D! r9 f. K% ^1 \8 p1 m
原创:高家升

) W& C5 Z! o6 C1 E- K- h! c* w, w& H
. f5 f% r. f+ D1 a" T

本版积分规则

选择云运维时代的王牌讲师-长河老师,助你轻松入门ITIL Foundation培训课程

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1|网站地图

Baidu

GMT+8, 2019-5-24 13:25 , Processed in 0.242661 second(s), 38 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表