-
Notifications
You must be signed in to change notification settings - Fork 0
/
chapter.strategy.xml
123 lines (101 loc) · 5.96 KB
/
chapter.strategy.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="什么是多维度架构">
<title>什么是多维度架构</title>
<para></para>
<para></para>
<section>
<title>架构与格局</title>
<para>俗话说：烙饼再大，也大不过烙饼的锅。一个人的成就再大，也大不过他的格局。</para>
<para>格局就是具备高视点，宽视野，深洞察，能够跨越时间和空间去看事物，同时不受思维定势的限制。</para>
<para>思维定势又称“习惯性思维”，是指人们按习惯的、比较固定的思路去考虑问题、分析问题，表现为在解决问题过程中作特定方式的加工准备。它阻碍了思维开放性和灵活性，造成思维的僵化和呆板。这使得人们不能灵活运用知识，创造性思维的发展受到阻碍。 </para>
<para>人的思维定势会被经历，职业，圈子，财富，出身等很多因素所困扰。</para>
</section>
<section id="架构师的大局观">
<title>架构师的大局观</title>
<para>我们从小的教育就是如何拆分问题、解决问题，这样做显然会使复杂的问题变得更容易些。但是这带来一个新问题，我们丧失了如何从宏观角度看问题，分析问题，解决问题，对更大的整体的内在领悟能力。这导致了我们对现有问题提出的解决方案，但无法预计实施该方案后产生的各种后果，为此我们付出了巨大代价。</para>
<para>而我们试图考虑大局的时候，总要在脑子里重新排序，组合哪些拆分出来问题，给它们编组列单。习惯性认为解决了所有微观领域的问题，那么宏观上问题就得到了解决。然而，这种做法是徒劳无益的，就好比试图通过重新拼起来的碎镜子来观察真实的影像。</para>
<para>所以在一段时间后，我们便干脆完全放弃了对整体的关注。</para>
<para>当今的社会，几乎所有的企业情况都是岗位职责清晰，分工明确，员工是企业机器上的一颗螺丝钉，我们在招聘下属的时候也仅仅是用他的一技之长。项目一旦立项，我们就根据项目需求针对性性的招聘，短短半年团队就会膨胀数倍，但效率并不是成正比增长。另一个问题是这个庞大的团队合作起来并不尽人意。结果是 80% 协调的时间，20% 实际工作时间。</para>
<para>很多技术人员埋头在自己的专业领域，更擅长解决自己专业范畴的问题，这样是不对的，技术人员应该培养广泛的兴趣，不仅仅要成为技术全栈，还要涉略艺术等领域。</para>
</section>
<section id="运维的三重境界">
<title>运维的三重境界</title>
<para>运维的三重境界你知道吗？</para>
<para>为什么公司在运维上投入很多，高层对运维也足够重视，花了不少钱，但是落地效果不尽人意。</para>
<screen>
<![CDATA[
发现问题-> 运维救火-> 事后复盘，再发现问题-> 再运维救火-> 再事后复盘，进入了一个死循环。
]]>
</screen>
<para>每次救火，领导远程等结果，看着运维这么辛苦，还会发一个表彰报告。</para>
<itemizedlist>
<title>运维的三重境界：器、术、道</title>
<listitem>器的层面：即工具的安装、配置及使用，包括对操作系统的熟悉程度、各种应用服务器精通程度。比如Linux、Docker、JVM、MySQL、Redis、Ngnix、Elasticsearch、Kubernetes、Prometheus、Grafana……</listitem>
<listitem>术的层面：方法论，流程，规范，架构。涉及技术点：负载均衡、埋点、探针、应用监控、故障报警、日志中心、性能调优、链路追踪、故障定位…… DevOps、AIOps……</listitem>
<listitem>道的层面：运维体系的建设，最终结果是为产品和运营服务，用户是否满意，运营是否满意，客服是否满意……</listitem>
<listitem></listitem>
</itemizedlist>
<para>80%运维无法突破器这个层面，最终只能做工具的安装和配置。18%有开发经验才能到达“术”的层面，从更高维度审视运维，明白运维的目的。最后2%具备技术背景和产品思维的人才能进入道的层面，明白公司角度要做什么。</para>
<para>所以你会发现运维团队常常是把技术武装到牙齿，你能想到的技术，能装上的都装上，能用的都用上，最终还是开发乱，开发环境乱，测试乱，测试环境乱，生产环境乱，部署乱，部署回撤如家常便饭。</para>
<para>每次出故障第一个发现的不是运维而是客服，是用户遇到问题解决不了，只能800/400客服投诉，客服找运维解决。</para>
</section>
<!--
<section id="monitoring.server">
<title>服务监控</title>
<subtitle></subtitle>
<itemizedlist spacing="compact">
<listitem></listitem>
</itemizedlist>
<section id="mysql">
<title>数据库监控需求</title>
<section>
<title>数据库监控指标</title>
<itemizedlist spacing="compact">
<listitem>
<para>数据库线程数监控</para>
</listitem>
<listitem>
</listitem>
<listitem>
</listitem>
<listitem>
</listitem>
<listitem>
</listitem>
<listitem>
</listitem>
<listitem>
</listitem>
</itemizedlist>
<screen>
</screen>
</section>
</section>
</section>
<section id="routing">
<title>Routing</title>
<section>
<title>Cluster Testing</title>
</section>
</section>
<example>
<title>dhcp vlan rip</title>
<screen>
</screen>
<para>取消策略路由</para>
<screen>
</screen>
<para>这个案例是基于源的策略路由</para>
<para>案例二</para>
<screen>
</screen>
<para>案例二是一个基于目的的测略路由</para>
<screen>
</screen>
<screen>
<![CDATA[
]]>
</screen>
</example>
-->
</chapter>