Get best of the week

建筑师清单

从本文中，您将学习如何组织在分布式数字公司中进行有效开发的过程，如何通过专家交流来实现这一目标，以及MTS示例如何实现这一点。

与许多其他现代公司一样，MTS也经历了所谓的数字化转型。简而言之，数字化流程和产品的推出已成为我们的首要任务。

对我而言，作为一名技术人员，这意味着公司业务的方向完全取决于IT系统的质量及其快速发展的能力。

当然，这是一个错误的定义，营销人员可以与我争论-甚至可以争论！但是对于您在下面阅读的所有内容，这已经足够了。



减少官僚主义-更容易发展


发生了什么变化：首先是公司管理模式。如果早期来自集中式企业体系结构（企业体系结构）的人员验证了每个项目，现在他们将发布技术策略（庞大而精巧的文档）并在其中培训建筑师。如何应用它已经是一百多个团队中每个产品架构师的个人问题。
 
一方面，这很好-减少了官僚主义，极大地简化了发展。另一方面，所有产品都以一种或另一种方式彼此交互，并且其中一个错误会影响另一个产品。

例如，在《软件系统体系结构：使用观点和观点与利益相关者合作》中，Eoin Woods和Nick Rozanski撰写了有关基本安全原理，确保最弱链接的文章。这意味着，如果您的IT环境中至少有一个受保护程度较弱的IT系统，则整个IT环境都将面临风险。仅仅因为假想的攻击者可以代表该系统不受惩罚地工作。

还有更多的示例在确保IT系统的设计和开发中的质量和一致性方面很有用。

内向的专家


我们想到的是：创建一个社区，以共享知识并传播最佳实践。这个想法不是新事物，也不是革命性的，而是可以满足数字产品开发的要求和细节。

  • — DevOps- support-;
  • , . , , ;
  • - , — . . -, ; -, ; -, ;
  • , ;
  • 由“审计员”团队组成轮岗，以便尽可能多的团队代表有机会分享知识和经验。

首先，我们组建了一个狂热者团队，为每个角色制定了一系列讨论主题，并培训了即席审核员团队。顺便说一句，培训是最困难的阶段，因为我们领域的优秀专家常常也非常内向:-)

结果是什么？




  • 研究产品团队的过程相当轻松。一个团队平均需要31天。在这段时间内，我们设法与团队活动的各个领域的代表进行沟通，草拟备忘录报告，并向产品负责人解释，以便他可以计划采取行动；
  • 工作的结果在很大程度上取决于专家。因此，重要的是每个角色都有几个角色：两名分析师，两名架构师等；其中一个已经进行了一系列的采访，而另一个只参与了交流；
  • 也有必要不断调整面试的方法，因为某些主题失去了相关性，而在它们的位置上存在一些以前没有人想到的问题。

例如，让我们看一下“建筑”方向的研究结果。
 
我们做了什么：

  • 与20个团队沟通；
  • 每个人平均花费31天。考虑到我们同时与几个团队进行互动，整个过程耗时六个月。
  • 揭示了与架构相关的180种风险。

 在我们的团队内部，风险分为以下几类：


风险1：设计

重要的是要了解，我们正在检查的所有软件系统都以一种或另一种方式经过相当严格的质量控制（例如，电信系统的监视周期长于开发周期），但对完善和效率没有限制。 。

为了理解我们认为的风险，让我们以示例的方式来看一下TOP-3。

对于年轻的产品团队，在剩余基础上开发软件体系结构时，情况很正常。最初，似乎一切都很简单，项目的时间安排很少提供认真思考架构组织的机会。然后，自下而上的设计方法开始起作用-在开发解决方案的各个组件之后，我们将它们组装成一个整体。

例如，我们决定生产用于远程医疗的数字产品。为此需要什么？

  • 我们可能需要在患者和医生之间进行视频通话的组件-我们制作了用于通话的组件；
  • 有时您需要定期聊天-这意味着我们为聊天提供了组件；
  • 我们需要从自动化医疗系统中获取病历-我们创建适当的组件；
  • 我们需要保持值班医生的时间表-我们也为此做好准备。

等等。

一切似乎都很简单，直到我们开始将它们放在一起为止。这里存在功能重复的问题-例如，聊天和视频通话本身就是非常紧密的应用程序（至少从医患交互的角度来看）。那些。风险是由于大量重复代码，我们必须非常重做我们的应用程序。

还是数据模型有问题。默认情况下，每个组件都在该模型中提供接口，这对于存储和处理此特定组件（而不是整个应用程序）很方便。
 
因此，值得记住一些简单的规则：

  • 自下而上的设计方法适用于技术复杂度低，团队规模小且需求多变的小型项目；
  • 对于大型项目和团队，设计方法是自上而下的，也就是说，当我们首先整体设计图片，然后进行编码时。

因此，在投入新项目之前，先问自己一个问题：它属于什么类型？
 

风险2：安全性

如今看来，人们对安全性的重视程度很高。每个人都记住这种平庸的必要性：

  • 验证用户
  • 授权他们采取行动；
  • 遵守最小特权原则；
  • 维护数据机密性；
  • 记录用户操作的审核日志。

但这是一个惊喜！对于为内部自动化服务的团队，这并不像其他所有人那么明显。看来，如果应用程序已经在内部公司网络上运行，那为什么还要对其进行保护呢？实际上，这是必要的，尤其是如果应用程序使用的数据被归类为个人数据。是的，入侵者侵入内部网络的可能性很小，但是没有太多的保护措施。
 
随着外部应用的发展，细微差别也会出现。考虑一个简单的，纯假设的示例Web应用程序，该应用程序使用密码对用户进行身份验证。会有什么问题：

  • 该应用程序可能允许您输入太简单的密码，然后很容易找回。
  • 可能无法保护应用程序免受暴力密码本身的攻击（没有验证码或类似的密码）；
  • . , - ;
  • URL- HTTP- ;
  • -, . , MD5 ;
  • - ;
  • - , . , , -;
  • - : , ..;
  • - HTTP-:

  1. - session tokens , ;
  2. - session fixation- (. . session token );
  3. - HttpOnly Secure browser cookies, session tokens;
  4. - .


因此，这里存在的风险是某人将获得不适合他使用的数据的访问权限。这可能会导致应用程序出现问题。 
这些仅是您可以在安全领域中谈论的示例。当然，理想的选择是实施安全开发生命周期过程，例如Microsoft推荐的过程。


风险3：表现
 
快速创建产品团队的挑战之一是三个字母的单词。这是MVP或价值最低的产品。这样的团队努力尽快创建一个应用程序，这将为公司创造收入，并且由于在应用程序开始时用户很少，因此他们通常在最后时刻考虑性能参数。但是，如果创建的应用程序突然变得流行起来，那么您必须考虑下一步该怎么做。

这里的建议很简单：应用程序性能与请求慢速资源的数量成反比。因此，所有策略都旨在减少请求数量或加速资源本身。在这种情况下，资源被理解为处理器，内存，网络，磁盘；有时将数据库或应用程序服务器视为资源也很方便。
 
  • 首先，我们查看是否有可能在分布式应用程序中进行客户端缓存，以便每次我们都不请求/计算所需数据时。如果有可能，那么我们可以节省网络请求，加载服务器资源以及他在那里所做的一切。
  • 但这是非常罕见的幸运，因此我们正在寻找是否可以缓存服务器。有了它，原理与客户端相同，但是性能增益略有降低，因为网络请求仍然会继续。
  • , . , , , , (load balancer);
  • , . — My SQL Cluster Grid Edition Apache Ignite (Gridgain).

好吧，当然，我们必须记住，缓存本身解决了访问数据的问题，但是由于算法的无效和预加载而产生了新问题。在某些系统中，缓存可能完全没有用。例如，在CRM（客户关系管理）系统中，很少有可能有效地缓存客户数据。在办公室工作的专家可以很快地从一个客户转移到另一个客户，并且根本不使用缓存。

因此，这里存在的风险是，如果不首先考虑如何“超频”应用程序的策略，将来最终可能会以很高的成本来重写应用程序。

总结


在本文中，我尝试讨论了如何通过专家交流来组织在分布式数字公司中进行有效开发的过程。在我们的远程开发时代，这样的过程变得尤为重要。它们使您可以破坏康威的法律，或至少将其最小化。
 
如果您决定创建自己的清单，那么我建议您不要从头做任何事情，而应该从现有文献中吸取教训。例如，在体系结构方面，Joseph Ingeno ISBN撰写的复审材料《软件架构师手册》非常有用：9781788624060

我的报告可以在此处找到

作者的作者：研发中心负责人Dmitry Dzyuba
 

More articles:


All Articles