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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1103|回复: 0

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

[复制链接]
发表于 2018-8-27 15:35:54 | 显示全部楼层 |阅读模式
本帖最后由 monicazhang 于 2018-8-27 15:53 编辑 9 |" @0 _( U* ^% |) B, Q
) \+ A5 ~# l, a4 c
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。

9 E: Z# `' P5 j" Q  ^# }$ M- y

+ Z9 {. z- G& c  @( Q
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:ITILxf.com" target="_blank" class="relatedlink">DevOps。

0 f( c* e/ U% t! G/ J3 G
1.png
1 `5 r& m/ n6 T& s9 }% b) h
DevOps

6 e$ u# ?& ?! S6 x+ k" \5 a0 @

6 [' j$ r9 d; R" l  P
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。
/ B7 b3 [- @4 F1 Q
# H* b* z6 s, [, U9 Q' p& q
DevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。
) C/ M! l0 a" R* E. D

6 u) S6 }: B' s( u- s
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。

) S& [, C6 S; e' x  N3 B

; l* }$ ]) b/ E  b# \% y1 @+ t% f$ `5 h

一、前言

4 u, U/ H, C' q- J' K
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。
+ k3 w( f3 F0 k+ x; j" _( ?
  V, m/ b: w7 P1 s+ O! V' D9 c
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”
7 B8 p8 v( ?" o  i1 n' f. k

( j: w1 M' U% J1 j! b' k# Y7 N
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。

4 Q3 I' G! ^! A% p: H6 |" J4 a  j0 A

9 a: y% n# \+ t
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。
% s" W2 j# w$ R9 @, d& n

9 l# ^0 b5 Z7 @: _  p: V0 S7 T* @
本文,我将自己关于这些问题的思考分享给大家。

5 F) h+ _% u4 [4 @0 s, y7 g
" t6 G5 L5 c; `

! G. i8 n: U% \& }

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


7 S6 [3 B4 c( d2 u" f
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?

& F8 _- I( d4 l4 a

- l# [" Z/ }! M9 d
如果让我们来从头设计一个平台,我们应该如何去考量?
5 V/ b3 p* D0 u9 W

0 n% H* W, f5 o5 m
1、效率 & 成本的均衡
$ z1 K; _( x% h$ m

, ?1 n* Y; ^' w" `运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。
1 f; z" \( w0 k/ z+ R

6 r  y, v" ?: _$ ~& A至于如何量化比较,就因系统而异了。

. `7 `/ _2 U! c$ o# b# G* l

; k. C& J+ C0 |4 T  L7 P! \0 X5 S/ P( W
2、体验 & 人性化$ B: S# J7 {' o. J

, A+ K, g' {" X. d3 Q
7 C" e5 v. O) w; m# o
为什么我要把体验放在第二位?
6 Y0 m0 g: ]' [' @
9 W! E: o( K1 m; x! c5 k* Y( I
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。

- f+ D% e% p2 ]: S$ b
5 B9 I& ?2 E0 }+ b  m
我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。
. Z4 ]8 B* G8 Z- P* d
. `* D# Q% p3 O
3、优秀的系统架构

" P2 o9 X2 M% Y* d. P; z2 X

9 K* U/ v$ ], D2 f( M3 N在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:

9 g; |) [8 i0 E$ Q, Q
1 |+ [% T, Q# {7 x
  • 稳定性:负载均衡、多活等。8 h7 i1 I- C  w
    4 a7 @) ], X; _0 Q/ J  h

! Q6 w0 J1 P9 p0 T
  [0 y: N9 y" o# X
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。1 v" L3 }/ [" }0 a

# g1 t- ~6 J- W; F  a
7 Q1 W) j1 L+ L. h9 v  l$ F
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。( g' s+ I6 w8 C/ a4 a

+ B( z# B) t& `& y7 |3 n( v8 o
+ @# u* F1 o: {
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。
    5 ~8 ]* n4 B9 _5 {

9 z8 @" w- H& W$ W' D
  e1 v9 t3 |" `! x
( c/ Q8 a+ e' t, S
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。
    7 j6 J. {1 h; j7 g' ~
8 V; H0 ?" v5 ^* {- n

% U6 ?7 @$ x7 ]6 `
* j! ?, `. U: x3 Z1 _' m9 J2 r9 V- `+ a% x% i* h; P) [1 x
、如何运维自己开发的平台?
- E1 g. j( R5 [! [. u

3 A5 V. E2 J! G" z0 o! {
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?
+ p( q. Y; g8 Q7 @* g: c

1 M; D5 [4 X9 L) K运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。
" D* J; {  q1 B3 n. z+ {( _# ~6 r

- @9 C! k; R5 [6 c! D# Y用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。
8 N1 A. }# o" L% P

9 o& p% I6 h( W% j. M
1、架构上的稳定性
- x5 _9 W" l1 J/ D9 i. }, M. Z5 J+ V& M3 D

4 _2 S- B9 c. F1 `- _. \2 V  _
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。
* K6 J) i6 O3 E2 }3 x( ]  O* [
( e* c5 M5 D' x( `+ M' y+ k7 e
2、快速地发现问题3 m6 J: M9 O* p, L, o$ A
$ W0 j( W$ n+ W3 R' j2 @+ F

1 F4 p& H, u) p4 ]" _' S7 h
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。
3 z) Y9 \! [# E# q

- ~& v. B- n4 Y2 u还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。
9 H$ @; O1 ?3 K4 ]% V: o

/ p! ?# Q( N, J4 K0 A
3、应急预案&演练
  a1 v' X& z  n3 \6 S. b9 z9 K5 N; D" b6 p

) c. d' ?) S, \0 B2 r- q
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。
2 k, r; T: ]- v2 L1 n9 Y1 ]

4 N: R6 h1 _. X因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。
3 Z7 g7 l: u5 {6 T; b# T4 o* _
# `5 q! `; \, r, Y8 P. o
4、自我保护9 K& b  ]1 ?3 T: f, T( p0 x
. t# p+ g. p" n& M/ N' ]% s
. ~( }# J* v1 J$ M
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:
1 Y& x6 {" H& c) i- U
1 h( x/ P! x8 u% x$ n, A
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。
      r8 d! s8 u( F( j# ], n& y& c. A
      I, P; f# k" [6 n! f8 J. `/ \

5 w7 `' b# ~* u
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。
    $ z( {, I: y# }* f6 ^& i8 x

    : r1 F6 M4 p5 N% R4 `

# m! y( y0 T' W( c5 ]0 R: L
  _' z  G. Z7 R% ~" P: q! ]/ C
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。
    ' P- \* s/ e- M- i

    1 X/ L: K! F4 v3 b

3 {1 [) B5 J( w' W, G% b' c
, F. q6 D$ r5 `5 V5 w- ^9 J$ L

2 t' ~& v8 k: I* V, d) s
5、容量规划
2 k6 Z' _( p& |: c5 }

/ d2 M$ S7 I) _* ?3 y9 ?1 z
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。DevOps
  ]2 Q: D( A) [. Z

4 d% i0 d! `' J笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。
  a/ ]  f# Y! y' i, |" f
' _: \7 F, y4 r  w
6、变更管理
# r" }- m1 C2 F0 b1 h
# K) }4 U5 k5 D  `9 P2 Y; b' ?/ s

: w- B3 B- X- S! z0 F& `6 s8 L( S
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:

( i6 T3 ^$ W/ c5 P% R/ j. _

" T- n& U- g3 ^4 j# A
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。8 Y7 ?8 \/ W  w9 t/ A/ A4 A$ D

    ! c# c# _! h; q  u/ W$ _$ f2 Y% P

& V% ~7 C% U: c# Y9 H
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。
    8 \2 p: l+ [5 q0 \. P4 ^+ P" |% W

    5 ^1 f' L/ {5 Q' f3 |8 {" E
9 j# {  `% t7 S9 ~7 R+ Z( N. K4 f

! h7 O0 i  S/ R
' `3 O' d, s2 L3 J) _
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。
    # i* j8 O3 ]$ A/ c

      ?! g" i$ ~, e; _$ {. `5 y+ B
$ U  j' _6 a  ]7 L4 x/ ?

) k: P. ^6 R# P# e
; u/ q  C( m4 r+ U* V, U

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


* M! O- ]2 Q& @! f' I


" T+ F! w  S5 S( ~$ P
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。
* r% N0 ]) R4 X2 J  o

; b  e+ ^1 r, H" D因此,我们要考量的,还有产品和需求层面的东西:
" Y' [+ q2 f0 N' G. ~
2 X) c" r! Q5 ]
1、需求管理
2 @& [  B+ H! ^6 o" E# i* {9 B- d1 l5 L- s' M( `! p. F

  w6 s1 s( a; s/ P7 f( U
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。

+ ?1 B; K( E+ z; V* s

+ v  m- N. G5 f
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。
    + l" G- }! d2 B& P2 b$ @
- c. l( J1 d: [" q0 u; z/ {9 S  e
2 n: f& n- Z9 ?: t( m5 F
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。* {$ n) F9 P2 G, F, w8 Z5 U9 T
8 r& j3 n1 j& U+ A. a7 ~$ v3 M+ j
  • 对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。
    9 a$ J- ~8 I& z" u. }8 ~8 v$ z
    : J0 [6 Z. [4 A8 w/ l5 O
1 ^% [& l* u4 m6 w! u: F
+ {$ Z2 Y  f' [7 y7 `
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。; f& n( q2 O- d5 U8 Y
    ' G( J" p- v2 E

5 Z6 X8 u2 c3 @  m3 T
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。
    3 L+ {2 H2 e- \4 p' G
    3 _9 m# G8 Y3 [0 ?1 s( Z
/ A3 L5 x  D+ u/ G- |( ?% ?

( |2 L( V# U3 J  i
  • 因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。
    9 @3 P1 K& H6 i" I

    9 M$ b# o% d5 e  |7 C* W, E& W0 e5 ?

( Y7 |9 ^0 E6 f& m

$ _/ P) C7 S" G! b! M& q  G
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。
    - e  U- V% o8 A; S0 ]7 i. }; y
    8 \0 t+ G, P2 z% G" Y4 A) V

( h) [2 K& R9 r
2、量化
" Q) o, c9 r1 Q: s& `- C
0 U* \( G+ s/ |% `9 I$ }, u9 x
% J  {" B% `/ O9 c
If You Can’t Measure It,You Can’t Improve It。量化是优化的前提。

9 i& I4 q$ A/ R
. e. o. w8 c1 m) I9 O! C+ ~; ^* l8 R
量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。
# W- c* C( J# t* D

0 a- x9 D1 w8 o& w
3、制定SLA
0 f" Z  i4 l' p% }  }, S
# o& U- }1 h4 e7 R) \
- F$ |! C: ^& t
简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。

6 m7 G# \' ~) D9 p5 ]( P
- F" B0 x( R0 c6 |" y! g, C
一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。
) h8 ?: z# K. @) y! ?+ y9 Q) N$ i; W
! i" `# v! ~) |" w4 @! C7 y, I$ y/ N
" f2 B. M; W" E) m* W" \$ C! u  u2 \

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


# }8 T* g' L# ], B


; M- f6 j9 D7 O  D
1、制定规范,并让规范在平台落地" `) ]0 N- J* u. U/ m
% t0 N+ I  X# T) h* m
5 R0 L' @- o4 x8 S
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。

4 V& a# W/ \) Q) `9 x  X

/ ^1 D; @* b" [1 ]1 I1 L" }  z0 Q! Z规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。

  e+ Y! O1 r7 W' Q5 ]

8 f* y$ y- `, W我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。

3 [" z* O7 M$ p' J, @* D2 o: ]; u

# T8 ^8 k) N/ ~+ R, _具体的实施方式可以考虑限制和引导两种手段:

- K# _* \& s  A  \$ @
, X5 |2 M" x4 g' [+ a
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。
    / ^0 S& M- u+ s2 V2 Q7 a9 ]+ d

' [" F& G' c+ k/ L* G
' E* U8 ?5 u: K  ~8 f1 J: ]
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。
    5 Y/ U. n& V: U3 A) p0 x

0 F' p; r* a* J2 O9 H/ O
2、协调开发与答疑9 J+ k3 _$ g) C6 T! U' q, Z

. G( }6 k5 j3 u+ \& c4 K. u! W$ w
" q, f' j0 ]9 u, K1 V3 k3 T
运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。
& ]$ o* @7 Q# j8 h% O' g! O

1 v4 m4 Y4 S8 i4 K0 x日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。
0 g, X) [- ]$ W0 D

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

& H) w7 q3 P" d7 O% g
1 W# h1 t/ u5 d
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:

* [+ F) ^1 y/ c
- I  D0 D" P2 o# c0 X: F
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;

    ' Y# a- z  f: F0 U) F- v
    ' h& W1 Z! |+ r( h: X

( W6 U( ]6 ~( c) X; `3 K8 x
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。
    8 y2 F/ Q9 H9 D( a& e$ g

* J6 I, |" F! D. h
我们也要同时思考如何与这类用户说明,提高小白用户的体验。

0 b- n0 `5 T( a! K- v6 R' y; w, J
0 e* L, j6 o) J. z
因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。

( a$ Q' @3 j# C2 t7 v" p

9 a9 U- d; _) A+ t+ m' ~2 ?
! `8 C. E  S* d

六、后记

9 T( P, m; N) V# Z

' `, j. }0 P& q" |) B, ?
时光荏苒,倏忽之间,我已从一个小小的实习生,成长到现在勉强可以独当一面的样子。这些年来,我一直在自动化运维平台开发领域耕耘。从刚开始重构服务树、权限系统模型、堡垒机登录;到后来的流量调度、监控系统报警与存储的深度建设,有很多个人的感悟与成长,梳理了一下,分享给大家。
& [/ v7 L, @9 y* q! }  t  R2 U
# V. `2 ], p1 q" A- Y
最后附上笔者思考本文时的脑图:
/ p  y  a2 w" x& G' N) z  N
0 ^( Y% P. k' _% b/ w
2.png
  p# y8 ]' M3 f: Z6 ?3 x  l" L
/ ]1 U4 U/ b; d+ o2 p7 v- \2 }% i, z6 H
& u) w& y  E) d: v6 T
- P3 ~- k) Q9 g, Q  o9 P# _  }
原创:高家升

9 I7 E+ F+ n* ~! v/ T2 X
) z6 f; p3 {6 W5 U




上一篇:五个高效率的DevOps好帮手
下一篇:DevOps实施过程中要把握好8个步骤
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-5-23 03:44 , Processed in 0.119223 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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