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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 423|回复: 0

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

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

参加活动:0

组织活动:12

发表于 2018-8-27 15:35:54 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 monicazhang 于 2018-8-27 15:53 编辑
+ I1 F& Q9 {3 H% \) M
8 f- s+ s6 o2 [( V) {1 ]& B
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。

# Q- h6 e1 r9 d( u' a! F; `
; B8 w! T5 u/ s5 m
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:DevOps
+ r' J; A$ a; x  ^# Y1 \% B) W: \: }
1.png
" T: e, D: U% @  T4 J
DevOps
/ }, g, k  X9 n( K1 U* P

1 l& }( r' l) p  Z5 R/ O+ }
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。
/ e% }# W) X  x3 x9 N3 ?6 N

( }0 X! v/ w2 r: Q8 Q. }DevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。

) g: C$ ]2 N/ h' c" ~

" I+ D4 y" Y  y5 V/ D" k
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。
4 f$ z' ?3 e) Q% N+ `
" d9 P# t4 V" |8 i; Y/ d+ P

一、前言

( B- v, x& S2 {! x$ `; c% K: V
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。
/ V) c: h0 @7 @
3 H# i5 O8 |2 b1 ?1 i- ^
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”
  j  R7 P7 T3 v

5 Y. A$ B3 V. k' e, l# _
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。

0 H" a$ f1 u' R8 d! |6 f1 I, A5 U
2 e7 |- Y8 C8 }1 r2 V6 J* G& ?7 J
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。

' U7 l8 w. R2 ]- o; G; j

! q1 ^* ]9 S/ G1 a
本文,我将自己关于这些问题的思考分享给大家。
2 }$ W/ ~9 a5 y9 x1 \

' J9 U# h; r( E

, [+ C, a, F2 h% i& p

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

, e; L; d3 w3 H# y* J% C: {; y  n
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?
% ?& `4 L0 T8 B/ i; i$ N
( H. p8 G) R- d. W) J( H$ q
如果让我们来从头设计一个平台,我们应该如何去考量?

7 n  [  K) k' n  l- ]$ t& h/ V9 @, c3 d

5 d) A' Y9 ~% l0 [. W  e& [
1、效率 & 成本的均衡+ F4 O/ ~2 Y2 g+ G  J2 e

2 N. ]' T9 L  Y; }运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。

1 b& v3 |! e" z$ C, ~/ f

( l9 Z4 a: i6 z' @# h至于如何量化比较,就因系统而异了。
6 x7 d  ^% }* T- ]6 d2 ?( ~
3 N4 ?% q+ [% k. n# x( _
2、体验 & 人性化
0 Y4 W5 i( T4 R# G3 F4 c4 B% y, ~2 _! B" [( Y) W

( k  m2 M) {- y/ E4 m9 o, t为什么我要把体验放在第二位?
/ v) s0 x7 S0 V) Z+ M- d

/ Q  f2 f2 h1 V6 ?7 \9 C
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。
2 r* q* a9 U" N+ r8 V1 ]/ Q
% n1 u/ b" @) L  f% ~
我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。

% X9 P- o4 V/ _5 f3 P" z; E7 \/ y% i
: k  n$ P$ n% T2 j/ C! ^$ Q
3、优秀的系统架构

& g) r4 p, H, Z4 A
7 ?6 i( ^, A; r: _5 l4 i) u
在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:

' O- s8 G" a- W

9 t8 z3 {# e2 M+ }( h2 Y7 X
  • 稳定性:负载均衡、多活等。7 G$ \$ j6 w1 k* ]; b* b  M
    , A/ o: V' D  j, }# V. p

. ?' I2 ?3 v7 ^6 {1 k3 B' t: w0 |6 b8 O9 C: I
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。
    , v8 V6 ?9 c0 V. }9 A6 [( d" s
. o% ]6 N* |9 P( N3 Q6 \
6 ]( g2 h3 B& v, M" \
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。
    , x, b: Z& Z1 E3 v& L1 M; X

8 @: w8 y  O3 @# s; ?
: H0 X( J- u! r" H1 L# ]. }3 z: H
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。
    & R$ b7 D7 ]" {/ b5 y/ R
. y# q& x( t: A6 \% z
+ W0 Q# f" W: x5 f) ?0 Y; M$ H

# v9 l0 u% u# V& f' h# p) m9 ?
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。
    ) N$ B2 X; r" E  s
* Z: n( @9 K- a  m8 S

) j/ m- H  S8 [7 I8 }
1 z* n4 i4 s  x2 H0 {2 n5 P& l, q" L7 o: k* H6 _4 ^
、如何运维自己开发的平台?
; \  Q: A1 c6 @+ z6 ^2 [7 E
. f1 P# J" |1 z7 p
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?
1 E6 X3 a1 X2 @5 O: Z

1 W: X8 v) A% j; U运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。

& U, s0 A5 V" F$ N5 K
/ W/ S; {: O5 R: H/ E6 O4 y
用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。
; @% L0 B8 m6 {
- K! L$ o' [8 f( I
1、架构上的稳定性
. ~- w6 Z4 `& P9 J( C
3 V/ U; m  ~$ E! J0 n: V
1 Z" l, Y% c, F( N  q4 z; H
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。

- ^% ]3 d( ]2 _) \1 H- X% F, ?
0 N; Z9 I# c( g- h0 W1 i
2、快速地发现问题
# T0 i. J% Q& @: i  s, T6 {" Z5 a" {3 ]; y" c$ k" K+ m. p

: v# q1 |* a$ M; }
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。

) P1 e9 N6 b; U! n% N; i* y% L

5 a; E) y& D8 i1 J0 x6 S还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。
+ V2 ]) y, v$ U8 m
* @+ L& S) B. {2 \0 x: ?0 e
3、应急预案&演练. x2 H+ ]( ^+ c) @, u3 v& t

, p( N. i+ a% P' G+ b+ e
* ~9 @# }. T* r- D$ W9 L; _2 |5 j
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。

1 Y' u0 Q/ ]# R* F7 l* d0 w: W! X

( }4 B3 E6 C; A) c! @, W因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。
0 h! q) x3 U: c: u2 _  a
8 _. d6 m: Y% r% \/ o- E  g, a! a
4、自我保护
8 r$ G- ?! D. o2 Y7 l: w- s
  ?  `. i4 }2 W

2 l' {2 }6 L' E
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:
  @6 ^- r' [( M' s7 v- e7 Z
8 V! j+ y* t& j& E1 L" ]
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。  Y4 x3 h: _6 d& e2 {. m

    3 r/ D% I  I$ O% x

% s, I) n. `% W  s
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。
    4 J4 F5 {1 ]! w0 W

    & b2 B& i/ U* ~( H* R3 J

7 o/ p* H) i2 l: g( W1 A6 X2 _
, M+ G* n5 j2 a% z% L7 i6 r
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。# \. h  l' C! h/ Q* X; c

    * a& N. I# D, g) ^

% W* m1 @) ?6 h  I, H2 p
0 ^; k5 O" W% W7 A

6 ~" ]( J  ]) J
5、容量规划
/ d  F$ o8 _$ G6 H( p
; y( t, {6 Z' P
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。DevOps
- m- y& d/ t; F) ^
5 R/ j1 s; ^. D# W' i+ P1 j1 I# W
笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。

5 Z% Z; A6 Q; A% ~1 L# T
. @: X: Z3 c5 ?( B; K: \  b6 }5 M
6、变更管理$ I( t) o- j4 Z

  a+ A: W  z* p* ^+ L
7 H6 u' a% Q9 _
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:

2 x' v" H- a% J5 F% Z$ k

- S. t/ f1 s' r- `
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。
    1 h! S7 p8 ^. l! d7 B7 ~5 {
    9 v4 ~# o% i! E9 H- L! E. S

* }9 P* o; L7 @+ L7 T3 K
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。
    , p$ k- c8 L: _2 S. e. S! C

    ( m6 K$ ^, q8 I5 |( I  x* m: ?, r
6 b" q' T  C* ?$ q5 m1 O7 j; P
; m# L3 p" q5 N/ T( v6 W

1 W% p, i' G* T0 U$ L) t* Q
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。
    7 R: B& U& G8 a
    ) l8 D9 j) j4 H0 F2 S' g' m

3 B! V" v' q' u/ L8 @

1 G3 @, T  E* b1 Y+ f( l
9 h  V' q& A1 y5 }/ d  g2 q9 M; U

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

5 F! [6 Z' ], j& j3 H$ v


0 J) ]  P$ I( ^% C( R) @$ _# _
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。
; D8 C  p7 X- B2 U+ {! \. {

# W" I0 `- N0 r% O因此,我们要考量的,还有产品和需求层面的东西:
! w" O2 u! d" g* O

0 w1 y$ \) ^) l1 t1 c
1、需求管理
+ u0 `3 f$ N5 P* t1 U
3 S$ E: }( W( a) Y0 S6 y2 ?+ N

" H/ L3 Q' l6 r+ ^0 Y3 z
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。

& Y* O' ~0 Q* c/ D  S7 K- B. m7 N
% |: I7 h# u0 z
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。
      B* r7 B# A& a# D% [% \) {! |

$ U' R5 M9 Y7 Q

( O" y- Y- J" E0 x& j
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。
    $ a; A; L; p$ j! {( L) j1 [  v# V

6 p: I: D: ~' }) q3 S! e
  • 对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。$ z/ Y/ U, o9 p) e

    # w( J4 b9 C  y3 W4 ~) m# `6 S
4 p' b& k0 I7 ^/ t) B

  D3 d  j  ^: J
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。
    " i) `7 h4 g" a5 l  q- h5 B
    5 r" E$ x& k% `% M# |
) d3 N, J+ x: `& ]
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。* Q( q7 `2 ]1 n5 [; o
    " U2 a, |" ?3 e( j

9 ^4 M' K( }- m9 {

# V1 S& X3 z8 p' z7 k
  • 因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。
    ' L! r& r$ ~2 C5 u1 o8 s1 f: P

    % x4 \' K- [6 h% Z  l$ @

9 c9 v. m4 s; @0 \- r: X) ?. ]

0 F% s8 t6 r+ N* b3 |3 @
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。

    7 Y* _. C$ |% j8 P7 G) ]
    * C8 F0 l8 Q- w- x- O& m

6 C7 |, n, s* p4 @7 a+ w, c/ c
2、量化* c  Q; r- Z5 k/ z4 d" v! j" H

, J) v8 B: J; s7 f! T4 Z5 m1 D0 Y

" _" h, \& ]( E4 i% Q. iIf You Can’t Measure It,You Can’t Improve It。量化是优化的前提。
. L9 E  t$ j- O: y9 c' c
" i# z7 K* W/ S1 Z9 y$ h, B
量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。

$ p( i  t; ?2 K' e" Z; t' O" a: x
! c* x, K2 M7 g  p
3、制定SLA+ g( }$ t) s5 x  A
! D% `9 L9 ]7 b+ f
# N" f. Q( e+ S, i) `
简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。

2 L  _( a& ~0 U, u/ O4 X+ n

% j2 `+ R; |0 v# h" X. y一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。

* M1 A# `0 R: S

$ `+ y+ Q7 T& l" d- G! ~. n! r% l

, G1 P4 N( ^' Y. T1 i! r

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


' G6 D' l/ K/ l7 k


' e1 A6 D2 |: D' U
1、制定规范,并让规范在平台落地& [4 H' `; |* G, q1 m% q+ N

7 F' H" U% t3 S9 y9 \
) k  C5 Q" ]% ?* M# I0 ~4 G" |& @
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。
" }6 W- o7 X! W

( |0 a/ E1 |5 N% j5 k规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。
& F- N. Y$ R7 I# o6 v
  a6 |/ |1 L# v4 b- o# b5 Y+ u. S
我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。

3 V. p% E  w7 H

' G9 {5 ?6 @( ?具体的实施方式可以考虑限制和引导两种手段:

& `, `& T+ M2 x* ?' d" q8 \& @

1 V+ C& v- \- b2 R8 U
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。
    , V% X9 p8 p  p0 P

9 q* G5 O6 m! F, {- }' P

4 ]" e7 T' w/ ~8 T) [' p
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。

    5 J* s5 d# s2 g
& l. ^, E1 j* F* i+ ~3 F2 b
2、协调开发与答疑
2 W# k+ j9 d4 K8 K8 J
4 D6 P1 q7 Z8 p$ _4 F

0 t$ v: |4 d+ `8 R3 i2 w8 l运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。
) F, T. D& m: v3 _# e; A
  S: Q! A  z, ~0 d  |1 Z% U# w
日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。
" O$ @2 a. ~. P, X% d/ S
. w2 B5 n' \. P& ~" _
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。
' X5 l  _" X, u, t8 N# X. g# ?

( x9 m, o) J: W4 G  P
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:
! }" E7 U' F% l/ u* ]

" N& `) N# v; ~) K
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;
    . z) g+ g/ H8 _, B4 Y$ o

    9 ^, a9 y5 T0 G; @4 n+ z

0 U- w( _9 i3 t
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。
    9 Z) M' J, [8 b: H2 e+ l

9 |" d9 a; G( A' Y$ E  M0 q0 q: \
我们也要同时思考如何与这类用户说明,提高小白用户的体验。
4 x1 v/ e0 E/ }
' x$ b1 Z% D- d. {4 t: t$ {
因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。

- ^  [9 l  u2 H+ |8 ?

/ W$ @1 z, D9 t! h9 I8 n

1 R+ J# D. `$ d0 L& ^1 H2 u( u/ P

六、后记

  `5 z# p2 u" d; R: Z; f
0 M! ^8 P, I9 f# Q. o6 N
时光荏苒,倏忽之间,我已从一个小小的实习生,成长到现在勉强可以独当一面的样子。这些年来,我一直在自动化运维平台开发领域耕耘。从刚开始重构服务树、权限系统模型、堡垒机登录;到后来的流量调度、监控系统报警与存储的深度建设,有很多个人的感悟与成长,梳理了一下,分享给大家。

- m4 `* }6 @, O1 Z/ S; C  H  Y

8 V8 ?( H  Y5 p; T) x! ?最后附上笔者思考本文时的脑图:

  x$ i+ c' |3 J$ R/ A; x
; S# e- H3 v$ \+ a% K
2.png
; g& `3 t: g7 V; _
2 J1 w! ^: `' Y1 F4 v
, J4 s) d0 t) M# {: `4 J& z4 @

) N4 k- s0 D+ q  {4 K) ?# ~( H
原创:高家升

' }" w( r3 q6 T+ }* t5 O+ v9 x6 p8 ^, C& d# Z5 {

本版积分规则

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

Baidu

GMT+8, 2019-8-17 21:11 , Processed in 0.270378 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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