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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

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

参加活动:0

组织活动:12

发表于 2018-8-27 15:35:54 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 monicazhang 于 2018-8-27 15:53 编辑
0 c- M4 J  F) C* D! b7 z- M) y! ~. Y. N. G$ f0 D& a$ M4 z. q6 {3 s/ L
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。

  E" U" }( q, Z1 l
: I$ I. E2 o4 i  k" |
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:DevOps
8 V* u  k7 z. C: z/ J2 P4 ^6 d
1.png
1 i4 ^- Z3 e3 Z, O; K. a
DevOps
& X9 O/ B2 Z. u
' H' g0 d3 q6 L' M9 O' a
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。

+ H; ^  |2 J0 M# o% }% s) v
, C4 m8 S  S, O, q6 ]
DevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。

4 q8 A8 e1 D) }
* d5 h. h; ^, m7 {
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。
! o, b5 f6 p" a" W: p

! g; {4 _; e, |$ p2 X) \

一、前言


6 X6 _; r) _& F. V% l5 s& }% I
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。
* X" o+ z7 S) r2 u1 k% v
! |+ F$ z% J" J1 G$ i
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”
) f- G  Y5 S- f. Y" \: Q
+ i9 S* j# a  n9 x' V" N7 m' B
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。

" w" O( v# ^" W+ }- a; L
6 d2 K- c$ j2 n9 `1 [
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。
& A. M3 P1 C# A5 ]( \4 y7 U

1 [" Z$ n0 U5 A7 y9 ~
本文,我将自己关于这些问题的思考分享给大家。
( a$ F6 t" K, R4 n

! z9 u$ x' \. r9 l6 I: I: v
4 a- P$ Q, v3 u: S6 q3 y7 p2 m, t0 l

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

) o4 w) X8 |" c: O* X' g% r
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?
0 z7 L+ U$ u5 _! M' B
6 j1 y+ Y% q' t2 O  k9 T
如果让我们来从头设计一个平台,我们应该如何去考量?

3 I+ C* M- w( w
8 [5 Y2 p# V. _/ b! \- \2 ]+ x  W
1、效率 & 成本的均衡
4 F7 Z' c: o: P. u' H

2 }7 B0 y! B8 U5 d运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。

  d7 s0 G7 i1 N5 u% Y4 `

& l8 y1 z) o: z' y7 z& W  \. j- F至于如何量化比较,就因系统而异了。
  g- V  \* S' ^

/ |# \3 z, D, p/ c% w  V
2、体验 & 人性化
5 Q; W$ i8 F+ d* f& o/ {! F  R
) E7 v4 x$ }. X2 H5 C$ @; c

5 ^; b! U7 K: ^% e2 t为什么我要把体验放在第二位?

: M) B. B& X7 s" m

! Q. R6 I7 s' }' O7 }6 h+ g
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。
% N7 d2 s. i3 `. v) _
6 H* t7 h/ n# h! H7 `; V! [
我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。

$ d: h5 m2 ]+ o0 n; {* t
& O; t3 i$ R" h
3、优秀的系统架构

! V7 Q% _4 |: ?( ~

/ M' F) U' l# r. i; _. j) |& u8 Q- B在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:

( j0 E1 j) t2 g6 c* I0 G5 m# N. q

3 a+ I; N5 A: c# ^7 Q2 [2 V
  • 稳定性:负载均衡、多活等。
    + Z7 M$ j! x  o4 E
    % E+ M9 J- S( Q( B1 B7 v
  o. J6 z2 V1 Z, N) B8 j3 X2 g
* Z) c: \4 p: H! T6 C0 g* }
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。
    + ~2 ?6 n( s+ ?: C

, j2 ]" v& i' N  P
. f6 ^8 l4 y* ~
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。
    + ?) M. a* Y+ H4 y
. J0 s8 v+ w) p4 G$ }
% e- E5 R- J4 h" Y+ M! v2 f0 P
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。
    5 |/ N$ ]6 a1 F3 n$ Z

, x0 @- H. S' a/ q8 K- M+ C( U* G0 s- x  L, p. n
8 n7 H' |" u) Q5 c, R0 M# L" v
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。
    , v& L9 c; K3 ~; L. ?

& x0 }, j& s1 {- b4 c
' l7 R4 N. Y! U% ?( ~# I, K
+ _1 A1 e2 ]" m+ V; F& e4 n( u1 d3 W! i1 U+ `) S2 Q
、如何运维自己开发的平台?
! s; s' G* `! }0 `
5 F# R9 x+ A2 L3 n5 H- L
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?
" s; f$ n' }* O! I% X& Y

0 r7 C3 z. U- q8 T5 k, H( m& d0 H运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。
/ \0 h% t6 D+ D" m% u4 L5 U6 g/ Z
9 P& O' I9 D" h4 Q* F
用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。
6 i0 e$ ^/ E3 h) C5 V* B( `  u# I

4 i9 r( |6 r, I2 v
1、架构上的稳定性
5 d* l9 |6 Z! G' m. b( q3 B) Y' M6 o* D% c3 T5 Q

% o8 O0 [3 i$ p+ I  ~
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。
- Q  L7 h$ m* _: p/ X

( c" ?4 N7 Z* [! F
2、快速地发现问题
0 I7 o8 a/ `6 c' S! r- E$ w3 G$ M1 v3 x$ Z7 G( M1 X

( n0 N  q# [8 Z+ k& I
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。
$ j0 X/ u8 K5 {' S8 \  d
8 N" S( f/ f  {8 e
还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。

& E( {/ V, r( \0 q& Q/ R& L. z/ u$ T

3 b) L* K" D+ }, K# y" s& |
3、应急预案&演练4 f4 ?5 O! o) M, ^% ?: e  }
8 U/ q/ d; S; f' _
. Z2 p, E' E" M6 H7 m5 G4 }3 r
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。

" O/ M8 W: ~% @' A. l0 h8 v
1 r$ G: n. E5 [7 G  t/ q
因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。

- n. P, f  b6 u! q8 m/ [! g# z

# O1 K% K. P/ w8 [
4、自我保护; ]7 ]# s5 s. g

7 h! v: o! U; i% A+ k

) h) r, Q  K; X6 s
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:
5 M) d0 G! l4 V
  O( o( V. n4 Z/ U( }, W( k6 l& O
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。5 Q6 ]6 W8 j! h! U9 O

    3 ]( y7 ?! x: d7 k0 }# o

3 p! p- ^$ Q) A  `* J+ E: x  a; |- b
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。1 d+ J6 T  t/ T8 j3 [

    ; Q  I1 _- y6 n  O7 a# ~( n1 Q7 h) d
! U1 ?+ n: a% `: D: n

. _3 t! ]2 w4 E0 I
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。* w0 ^! a* |& k. q5 y' `; g
    0 Z. ?) j! {4 }9 u% r% b& R
* P- J4 ~. k7 _8 i; K2 V( Q
2 g3 v+ f# \* h/ G5 J- c: r

' v# j9 q2 s4 L# H; G3 _
5、容量规划
; p7 C. N8 P) B, T0 T; u

0 H+ V7 m7 d$ A+ E2 I3 }  {2 S
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。DevOps

) X6 q; ^6 ?. M
; j* s. B% L; d) ?/ m
笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。
+ t6 k9 N# M7 C6 S8 t' `) [

( Y0 D- P# f$ h+ U
6、变更管理2 W) Y0 Y" B; a  y; ^" N

- l, H9 d: p1 D. N& f

. k8 j" M! b+ \- V1 p; B% G* a
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:

. z- u- ?! a6 C0 P
. s% S" d5 |; W7 O7 D# s9 S
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。. ~9 e9 a7 s% [

    9 i; L/ S* G& @) c! ^( `/ V& s

. o+ e8 L7 Z0 R; Y" u
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。0 j4 F: v5 S- R0 a. Y& u1 r
    # U- J: y# v: A0 d7 L. I1 U5 o# }  e

, p7 p9 U  e! l1 D
! m+ ^& d. b) A0 T" m1 z1 n5 ]
7 H8 s% V- ]' A9 X
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。9 T$ V/ f6 o% f8 h! m6 I, f

    $ N! \9 c. X) c' {6 s  f

8 V7 U) y" g$ g. \

5 c) G/ \8 A. ~- R
/ h* E& W6 k+ [

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


, s( \" O! F4 k0 }  r3 V6 F


% Z! j8 S- \$ T6 N$ Y6 G
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。

) m2 G) {5 j/ K- |9 B

7 U0 @7 _% g! p1 T) p) [因此,我们要考量的,还有产品和需求层面的东西:

& _6 G+ ~; X, ~9 C( J9 M
7 ^* I% @# }4 q4 U. V+ L. a! n4 G
1、需求管理) M9 R/ ^8 B# f8 t' b' [3 H" ?

. s. k! A7 m4 {2 x5 F

) O8 Y1 `" }7 Y) S# B
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。

! K* T  e# ^% S# S8 u

( J- L( }. s% [1 D# h; p1 ]
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。

    ; `" ]$ p& C" Z( }4 w$ K

2 t2 a* g& d* j5 `: b7 [* x$ h
% S5 N' i5 u- h7 |5 N! m* n! ~
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。
    0 F1 h( z0 f: W" N$ H

/ ?8 J/ k% W1 L2 y+ g7 ~  h& B
  • 对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。; J0 Q! M5 K# W  [$ d4 ~7 @

    & t* Y9 u  A. s( G

- ]% }3 `' E2 }

2 V! M3 I5 E) @: w5 H% c0 M) }
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。8 ]/ k, A. t; i# t! a

    ) P6 k( |0 o2 N, O
, ]* e$ [4 L* C4 @% g9 J0 T
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。
    $ ?/ |9 m5 w+ v  h

    ' m6 B# T8 ]: O5 G
7 E+ x( s3 l  Q' M( Y" k' S) z  d" q

$ D4 ]( r# g( I: k
  • 因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。6 Z6 A0 P, \# {; _  G

    - v) D; U$ Y3 ^2 {1 I2 o* s" \

2 Z, b' A1 N5 }' ~5 A4 d8 r( D$ b
( C9 @# D* y# Z4 O  X
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。

    ( _; I% z8 O6 w" G/ {
    / ^% O/ W5 w; `6 c7 {

( v( B- P0 S; A6 W, G% |
2、量化( Q! e: r( i8 k  @
' }" e5 l( c, h' j9 ^$ @% p

! N0 f9 o5 T: |" AIf You Can’t Measure It,You Can’t Improve It。量化是优化的前提。
9 h  D3 W3 V5 z' ?5 `! N

% Y2 J5 K, W3 w9 ^# s量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。

6 x% w- @0 r5 r0 V

4 b( a8 m& b% t! ?0 [: T+ V, r# Z8 Y
3、制定SLA7 f* ]5 J, G/ \0 a5 ]) ~- n

' u, X: h/ g% o& H9 z; y$ ?+ K* s0 P
' D( o. C# J; N: }
简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。
6 z& F  s2 V. s
2 t& z+ Y: n8 S% k" z3 D8 a  y
一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。
, |1 @$ Q6 r1 ^3 Z# m, @% Z) h
$ ]3 k& y' u7 v) R
7 W9 }2 l, y5 N9 b- x  k1 b- @/ U

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


+ Y; `6 m2 Q- `8 A7 i3 C. x

# |5 E% `1 U* I0 f- T( ]
1、制定规范,并让规范在平台落地
- M' ?  G" Y# J
: q  S1 O) h: O: ?7 ]( v; r1 l6 K2 ?

3 E. p& }: Y4 N( _; I
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。

/ _5 `! j) M3 N2 S
) j$ b  y) r1 y; B
规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。

+ {8 q7 u: @1 S- e

6 N, T' R9 h* k" i+ W5 R9 b我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。
  x* O6 T1 x  d6 _; ?2 a+ J

% S  B  U7 T" |具体的实施方式可以考虑限制和引导两种手段:
4 Y  U7 N$ X& s8 t$ k0 t

% z- l" x( b) F8 s( j
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。

    " a2 g( w+ N+ C  n
1 i+ c& _3 `5 D# ]9 l
% i4 U' U$ e1 ]; E+ C* e) r
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。
    * E' G* ~4 Q5 ?2 d" Z, M% U
9 c5 s1 _# l( U
2、协调开发与答疑
- Q+ v7 K- G  D5 m
& R, v/ F. }/ x5 M% C+ U1 \* I: L

7 x5 r( O/ u& r" B  ?& M  h  O0 g运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。

4 O1 w2 [' |; j6 F. {2 b
  {: I$ D. l- \* \0 x) R
日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。
% l4 n) c" R- n! `8 V9 U

; i, _/ b$ p6 {6 [
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。

6 X' `2 h' t  Y( |

: Y3 F8 w1 F  v8 G! L& {" K: Z
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:
# A* v( Y) u2 ?% E( S. T+ u7 ]" v

6 f3 g' t* m: B% N* V6 S! N+ m5 ]
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;

    3 ~. M9 e. l, a/ ~( W' _/ K
    . F" s2 h- T" m! Y! v
( a7 O3 {' W. G) @2 T2 k
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。
    4 e, Q) Q( l+ X$ n* E7 m
- L8 a8 T1 w. O. P# Q' v6 o
我们也要同时思考如何与这类用户说明,提高小白用户的体验。
& ]# Z1 v7 t' o% m) j9 \. S

2 N% n8 ^" R. U2 a因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。
0 [- E$ z3 k* s: a( ]% m; H5 T

+ A0 g9 y6 Y3 S, a& y0 g( M
5 Q/ y7 o0 S3 z* ]: n7 c

六、后记

0 J4 T# v% z3 [5 L5 N& `

7 m0 n" C- |+ p7 h' k) `0 S
时光荏苒,倏忽之间,我已从一个小小的实习生,成长到现在勉强可以独当一面的样子。这些年来,我一直在自动化运维平台开发领域耕耘。从刚开始重构服务树、权限系统模型、堡垒机登录;到后来的流量调度、监控系统报警与存储的深度建设,有很多个人的感悟与成长,梳理了一下,分享给大家。

: Z5 h. d$ e, F7 A. J

0 f- ~" L( _2 I9 K  ~% b2 L; F2 a$ F# i最后附上笔者思考本文时的脑图:
' K5 q8 a! @- r6 {) q% |1 H& W/ `- R

9 m& Y& i- }3 e, i8 W5 B
2.png
7 n. U! E% d  i- H) J
. W; Q, j) @- O4 x$ U& C# J% ~

4 ~/ V  e1 `5 P3 C
+ [0 I9 V. k. I+ R: G
原创:高家升
9 {7 d; x# Y' z6 Q' E

' r4 ]8 A; T$ M4 M. n

本版积分规则

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

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

Baidu

GMT+8, 2018-11-14 13:06 , Processed in 0.260056 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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