就资产而言，世界上最大的银行之一保持着 DevSecOps 的思维方式，探索 AI，并消除噪音以鼓励其工程师进行探索。
一目了然
- 摩根大通拥有超过 35,000 名软件工程师开发其解决方案。
- Sridharan 和她的团队构建了一个开发人员平台，以提高开发人员的工作效率并加速公有云迁移。
- 摩根大通（JPMorgan Chase）采取谨慎的方法来实施人工智能战略，包括GenAI。
就跨国金融服务公司而言，摩根大通在其工程师及其所服务的运营方面拥有重要的足迹。摩根大通拥有超过 35,000 名工程师构建解决方案，因为它服务的客户群包括数百万家庭和小型企业以及 3.9 万亿美元的资产。
监管审查和客户需求的结合意味着公司的工程师需要获得资源，以帮助他们快速高效地运营，同时帮助公司满足合规期望。 数字化转型网（www.szhzxw.cn）
摩根大通（JPMorgan Chase）工程师平台和经验全球主管Sandhya Sridharan及其团队构建了一个集成的开发人员平台，以帮助他们有效地部署解决方案，提高开发人员的工作效率，加速公有云迁移，并实现现代工程实践。她与《信息周刊》谈到了在大型金融机构内协助工程师所面临的挑战和考虑因素。
您已经采用了DevOps的思维方式，并且您的开发规模很大 – 在我们深入研究细节之前，您计划从哪里开始在这样的水平上运营？您首先希望工程师能够为您的客户提供服务？
授权工程师确保他们拥有完整的端到端体验 – 我们如何做到这一点？以多种方式。首先，有哪些最佳的行业实践、解决方案和工具？第二种是倾听，让那些客户咨询委员会、高级从业者或产品柜不仅要了解他们的业务优先事项，还要了解他们的摩擦点在哪里，他们想做什么，他们的生态系统是什么样子，等等。
当我还是一名开发人员时，环境是如此简单。你只是写代码;你把它作为一个启动的构建系统签入，然后有一个单独的团队去打包你的软件，然后把它交付给客户。如果你现在看，在期望工程师了解多种技术、基础设施、网络等方面，存在认知超载。我们如何抽象所有这些复杂性是我们开始的地方。我们如何构建一个更加自助的模式？与我交谈的工程师越多，除了 – “我想要一个可靠的系统;我想要这个快速发展的东西;我想抽象出控件的复杂性，“除此之外，它们的所有要求都略有不同。在语言支持或基础设施支持方面，人们认为是现代的，但对于其他工程师来说却是不同的。拥有自助服务的能力，这种灵活性至关重要。
为平台奠定基础层非常重要。毫无疑问，这是行业最佳实践，同类最佳工具，工程师试图解决什么问题，业务优先级是什么，然后我们如何构建一个平台，不仅可靠、可扩展、安全，而且足够灵活，让工程师拥有自助服务功能。这就是我如何构建基础层，以确保我们构建的任何东西都保持强大。
您如何以有意义的方式为如此大规模的工程师引入和维护 DevOps？
DevOps 更像是一种思维方式或一种文化。肯定有一个平台和工具方面可以实现这种文化和思维方式。首先，从规划和构思阶段开始，他们在创建长篇故事时需要哪些最佳实践和原则。我们称之为规划和构思阶段，导致他们何时编写和提交代码，他们拥有哪些功能，并确保内置安全性。不仅仅是 DevOps — DevSecOps。 数字化转型网（www.szhzxw.cn）
确保团队有培训、支持和意识，但也要从工具的角度提供这些护栏，为他们提供安全的环境，让他们从中取得进步，就像内部循环中的开发人员一样，他们将软件开发到开发或暂存系统上。在他们投入生产之前，每一步，平台都会刺激他们，说：“嘿，你提交了一段新代码。我将启动安全扫描，“例如。“我将启动代码覆盖率，因此在这个过程中，我将运行你所有的单元测试、集成测试等等。
使用 DevSecOps，有时会有安全性的推动和拉动想要减慢速度。有什么特别的技巧吗？你如何找到这种平衡，让所有不同的部分都能发挥其潜力，同时又不会减慢速度？你如何找到这种平衡？
总有一场非常有趣的拔河比赛。当你在系统中有如此广泛的规模和变体时，有些团队希望在他们投入生产之前有更多的自由。有些团队希望在它进入拉取请求之前做好检查，所以要找到平衡点。我们有政策服务。每个人都需要遵守一项全公司范围的政策。例如，生产中没有 V1、V2 漏洞。我们在什么时候阻止它们取决于业务线可以基于平台策略构建的策略。 数字化转型网（www.szhzxw.cn）
例如，在你进入开发或暂存环境之前，一条业务线或一组应用程序就会消失，“我希望所有的扫描都完成，代码覆盖率已经完成。他们可以去给我们的策略服务添加一个标志，上面写着“在一切都通过之前，甚至不能做一个部署”，而其他团队可以说，“我可以升级到UAT”，但平台不允许他们在进入生产环境时对此进行任何更改。在它们投入生产之前，您必须遵守某些标准。
您必须满足我们在监管要求方面商定的 SDLC 的所有控制目标。在生产之前，您必须满足某些同行评审、代码覆盖率标准。
在考虑规模和复杂性因素时，是否还有其他考虑因素？对于此操作的规模，是否还有其他考虑因素？
生态系统中的变体。命名一种语言 – 我们有Java，Golang，C++，C#，所有这些。我们部署到公共云、私有云、VSI、PSI 以及一些大型传统系统。我们是一个受到高度监管的行业，因此摩根大通（JPMorgan Chase）是全球最具系统重要性的银行之一，因此我们非常重视这一点。对我们来说，这是一项重大的义务。我们尝试自动化，因为手动过程非常非常容易出错。 数字化转型网（www.szhzxw.cn）
回到我之前的评论，我们如何让开发人员对平台感到兴奋，他们是否使用该平台，然后他们免费获得所有这些。很多监管的东西，即使它们已经被抽象出来，复杂性也是从它们中抽象出来的。只需使用该平台，他们就可以获得所有护栏和安全的环境。我们知道，投入生产的代码已经满足了所有监管要求。因此，绝对不仅仅是规模和复杂性 – 我们部署到的端点提供商，众多，监管环境是一个重要因素。
你如何衡量生产力或成功？在部署和交付方面，您通过哪些方式支持工程师？
一个肯定是围绕最佳实践、培训，我们有开发人员论坛。我们拥有我们称之为史诗般的业务线、工程师平台和集成经验。我们有技术酒吧的概念，我们支持它们的方式有很多。对我们来说，最大的成功是确保平台足够直观，以至于他们去二手资源来微调他们正在做的事情。从平台开始，从您构建的规划和创建阶段开始，集成测试解决方案以进行部署和操作，包括端到端可观测性的全部范围、所有可观测性解决方案、所有可用的测试解决方案，以及 Sonar 等代码质量工具，以及所有同类最佳的安全扫描工具。
所有这些都内置在平台中，许多最佳实践也内置在平台中。例如，如果构建通常需要几分钟左右的时间，那么平台会主动向他们强调这些是优化构建的可能方法。如果他们正在部署，那么部署也是如此，然后作为我们证据的一部分，如果他们有一些逃脱的缺陷或事件，我们如何在他们投入生产之前抓住并强调这一点？这些是我们从平台提供的功能方面的方法和工具，以及当出现问题时进行某种最佳异常检测，以便他们可以停下来重新审视为什么突然之间，这个特定的构建比以前的构建花费的时间要长得多。为他们提供更多的分析见解，以便他们可以更早地做出决策，在生产中发现它之前。
这一切如何影响摩根大通更广泛的 IT 战略，包括云迁移和现代化等？
其中不可或缺的一部分。无论是加快发展，还是整体现代化转型，保护企业。我们在公司有各种举措，我认为平台上的开发人员工具至关重要，因为它支持了很多这些功能。我举了几个关于保护公司的例子。当我们使用开源库时，我们是否使用经过全面扫描和审查以供内部使用的开源？我们是否有完整的生命周期管理？ 数字化转型网（www.szhzxw.cn）
我们在内部构建的内容，以及我们使用的第三方软件，所有这些都要经过威胁建模、漏洞检测和生命周期管理的视角。然后是现代化。在部署到公有云方面，我们至关重要。我们支持自动、持续地部署到公有云，然后，如果你也是一个微服务，你如何跟踪你的所有依赖项，并行部署到生产环境？许多应用程序都具有现代化的多策略，无论是重新托管都是一种策略，因为它有好处;还有平台重构 — 你可以保留你的应用程序代码，但也许你只是在改变你的数据库，并利用一个更现代的数据库;然后重写。
如果你看一下这些现代化的所有三个支柱，当然还有第四个和第五个要素，但如果我看一下三个核心要素，就会发现工具链在部署方面是非常不可或缺的。例如，无论您是部署到新的数据中心还是公有云，然后配置您的基础设施，因为这一切都通过平台进行，然后提供完整的证据，即从编写代码或摄取代码到部署代码的完整可追溯性。因此，它是现代化之旅中不可或缺的一部分。
您关注哪些外部因素？随着新技术（包括人工智能）的出现，您如何过滤掉噪音？
这是一件困难的事情，尤其是在我们运营的规模下，因为有很多有吸引力的工具，供应商在营销和销售方面做得很好，尤其是对摩根大通。我认为首先是跟踪我们的战略，并确保我们专注于我们的战略、愿景，然后我们如何为开发人员创造无摩擦的环境，以及这个特定的工具或解决方案如何关键？我认为保持这一点非常重要。 数字化转型网（www.szhzxw.cn）
当然，在受到高度监管的情况下，该解决方案和功能的安全性如何？整个行业总是有很多工具，有利有弊，尤其是——你指的是人工智能——众所周知，人工智能，尤其是现在更多的 GenAI 和 LLM，可以帮助加速工程师，无论是编码辅助还是其他一切。我们的全球首席信息官Lori Beer在投资者日上分享说，我们正在探索市场。我们正在探索其他机会，但当我们实施任何人工智能战略时，我们必须负责任，包括我们想在各种应用程序中使用GenAI做什么。
这是一个非常令人兴奋的领域，我们的工程师对这个潜力感到非常兴奋，我认为他们知道这个领域会有更多的发展。然后我们就有了这个，无论是这些ML模型的安全性，还是开源的安全性，然后是整个工件管理空间，甚至在数据库空间中，都有向量数据库–发生了很多演变。我们喜欢创新，所以我们想看看有什么新东西，这样创新就不会停止。不断创新，不断学习，但是在生产中使用什么，生产代码在哪里使用？
我们是否通过使用它来保证公司的安全？它是否会在经验方面考虑乘数因素？这是我们在实际采用这项新技术并将其投入生产使用之前的一些想法。 数字化转型网（www.szhzxw.cn）
英文原文：
JPMorgan Chase’s Sandhya Sridharan Talks Empowering Engineers
One of the biggest banks in the world, in terms of assets, maintains a DevSecOps mindset, explores AI, and cuts out the noise to encourage its engineers to explore.
At a Glance
- JPMorgan Chase has more than 35,000 software engineers developing its solutions.
- Sridharan and her team built a developer platform to increase developer productivity and accelerate public cloud migration.
- JPMorgan Chase taking a careful approach to implementing AI strategy including, GenAI.
As far as multinational financial services firms go, JPMorgan Chase has a significant footprint when it comes to its engineers and the operations they serve. JPMorgan Chase has more than 35,000 engineers building solutions as it serves a customer base that includes millions of households and small businesses and $3.9 trillion in assets.
The combination of regulatory scrutiny and customer demand means the firm’s engineers need access to resources to help them operate quickly and efficiently while helping the firm meet compliance expectations.
Sandhya Sridharan, global head of engineer’s platform and experience at JPMorgan Chase, and her team built an integrated developer platform to help them deploy solutions effectively, increase developer productivity, accelerate public cloud migration, and enable modern engineering practices. She spoke with InformationWeek about challenges and considerations that come into play assisting engineers within a massive financial organization. 数字化转型网（www.szhzxw.cn）
You’ve adopted a DevOps mindset, and your development is at significant scale — before we dive into fine details, where do you start to plan to operate at such a level? Where do you look first to empower engineers to then service your customers?
Empowering the engineers to ensure that they have that full end-to-end experience — how do we do that? In multiple ways. First, what are some of the best industry practices, solutions, tooling? The second is actually listening, having those customer advisory boards, senior practitioners, or product cabinets to understand not just their business priorities, but also understand where their friction points are, what are they trying to do, what their ecosystem looks like, and so on.
When I was actually a developer, environments were so simple. You just write code; you check it in as a build system that kicks off and then there is a separate team that goes and packages your software and then ships it to customers. If you look now, there’s a cognitive overload in terms of expecting engineers to know multiple technologies, infrastructure, networking, and so on. How do we abstract all of that complexity is where we start. How can we build a more self-service model? The more engineers that I speak to, other than — “I want a reliable system; I want this thing that goes fast; I want to abstract complexity of controls,” — apart from that, all of their requirements are slightly different. What one considers modern, in terms of language support or infrastructure support, it’s different for another engineer. Having the capability to do self-service, that flexibility is critical.
Laying down that foundational layer for a platform is very important. Definitely it is industry best practices, best of breed tooling, what are the engineers trying to solve for, what are the business priorities and then how can we build a platform that’s not just reliable, scalable, secure, but also flexible enough for engineers to have self-service capabilities. That’s how I go about building out the foundational layer to ensure that anything that we build upon that stays strong. 数字化转型网（www.szhzxw.cn）
How do you introduce and maintain DevOps in a meaningful way for engineers at such scale?
DevOps is more of a mindset or a culture. There is definitely a platform and a tooling aspect of that that enables that culture and mindset. First and foremost is, right from the planning and ideation phase, what are some of the best practices, principles that they need when they’re creating their epics. We call it the planning and ideation phase, leading to when they’re writing and committing code, what capabilities they have, and also making sure security is built in. More than DevOps — DevSecOps.
Ensuring that the teams have the training, the enablement, and the awareness, but also from a tooling perspective provide those guardrails, provide that safe environment for them to progress from, like a developer in the inner loop where they develop their software onto a dev or a staging system. And before they go to production, every step of the way, the platform kind of prods them, saying, “Hey, you committed a new piece of code. I’m going to kick off security scanning,” for example. “I’m going to kick off code coverage so in the process I’m going to run all your unit tests, integration tests, and so on.”
With DevSecOps, sometimes there’s the push and pull of security wanting to slow things down. Are there any particular tricks for that? How do you go about finding that equilibrium, so all the different parts are operating to their potential but also not slowing things down? How do you find that kind of balance?
There’s always a very interesting tug of war. When you have such a wide scale and variants in the systems — there are some teams who want a lot more freedom just until they go to production. There are teams who want to do checks well before it makes it into a pull request, so kind of finding the balance. We have a policy service. There’s a firmwide policy that absolutely everyone needs to abide by. For example, no V1, V2 vulnerabilities in production. At what point do we block them depends on the policy that the line of business can build upon, by the platform’s policy.
For example, one line of business or one set of applications will go — before you even get into a dev or a staging environment — “I want all the scanning to be complete, code coverage to be done.” They can go and just add a flag to our policy service that says, “cannot do even a single deployment until everything is passed,” whereas other teams can say, “I’m OK with going up to UAT,” but the platform will not allow them to make any changes to that when they go to production. You have to abide by certain standards before they go to production. 数字化转型网（www.szhzxw.cn）
You have to meet all of the control objectives for SDLC that we have agreed upon in terms of regulatory requirements. You have to meet certain peer reviews, code coverage criteria before production.
Are there additional considerations that come into play when you’re looking at the factors of scale and complexity? For the size of this operation, are there other considerations that come into play?
The variants in the ecosystem. Name a language — we have Java, Golang, C++, C#, all of that. We deploy to public cloud, private cloud, VSI, PSI, and also to some large heritage systems as well. We are a highly regulated industry, so JPMC [JPMorgan Chase] is one of the most globally, systemically important banks, so we take that very seriously. For us, that’s a big obligation. We try to automate because manual process is very, very error prone. 数字化转型网（www.szhzxw.cn）
Going back to my earlier comment about, how do we make developers excited about the platform, is they use the platform then all of this they get for free. A lot of the regulatory things, even though they’ve been abstracted, the complexity is abstracted from them. Just by using the platform, they get all the guardrails, the safe environment. We know that the code that goes to production has met all of the regulatory [needs]. So definitely more than the scale and the complexity — the endpoint providers that we deploy to, the multitude of that, the regulatory environment is a big factor.
How do you gauge productivity or success? What are the ways you support engineers in terms of deployment and delivery?
One is definitely around best practices, training, and we have developer forums. We have what we call the epics my line of business, engineers’ platform and integrated experience. We have the concept of a tech bar, so many ways that we enable them. The best success for us is in making sure that the platform is intuitive enough that they go to the secondary sources to fine tune what they’re doing. Right from the platform, right from your planning and creation phase you build, integrate testing solutions to deploy and operate, including the full gamut of end-to-end observability, all of the observability solutions, all of the testing solutions that’s available, and code quality tools like Sonar in the mix all of the best of breed security scanning tools. 数字化转型网（www.szhzxw.cn）
All of that is built into the platform and a lot of the best practices are also built into the platform. For example, if the build normally takes maybe about few minutes, then proactively the platform will highlight to them these are possible ways you can optimize your build. Same thing around deployment if they’re deploying and then as part of our evidence, if they’ve had some escaped defects or incidents, how do we catch that and highlight that before they go to production? These are the ways, the tooling in terms of capabilities that we offer from the platform, as well as some kind of best anomaly detection when things are going wrong so they can stop and relook at why all of a sudden, this particular build took a lot longer than the previous build. Giving them more analytical insights so they can make their decisions earlier, much earlier before they find it in production. 数字化转型网（www.szhzxw.cn）
How does this all factor into the broader IT strategy at JPMorgan Chase, including for such things as cloud migration and modernization?
Very integral part of that. Whether it is accelerating development, the overall modernization transformation, protecting the firm. We have various initiatives in the firm, and I think the developer tooling on the platform is critical because it enables a lot of those functions. I gave several examples around protecting the firm. When we consume open-source libraries, are we consuming open source that is fully scanned and vetted for internal use? Do we have a full life cycle management around that?
What we build internally, as well as third party software that we consume, all of that goes through that lens of threat modeling and vulnerability detection and lifecycle management of that. And then the same thing with modernization. We are critical in terms of deploying to public cloud. We enable that automatic, continuous deployment to a public cloud, and then and if you’re a microservice as well, how do you track all your dependencies and do parallel deployments to production? Many applications have the multi-strategy for modernization, whether it’s to rehost is one strategy, because there’s benefits to it; there is replatforming — you can keep your application code, but maybe you’re changing just your database and taking advantage of a more modern database; and then rewrite.
If you look at all three pillars of these modernization, of course there’s a fourth and a fifth element to it, but if I look at the three core things, the tool chain is very integral as to deploying. Whether you’re deploying to a new data center or a public cloud, and then provisioning your infrastructure, for example, because it all goes through the platform, and then providing that full evidence, the full traceability across from when the code was written or a code was ingested, all the way to when it got deployed. So, it’s a very integral part of the modernization journey. 数字化转型网（www.szhzxw.cn）
What kinds of external factors do you pay attention to? How do you filter out the noise with new technology emerging, including AI?
That’s a hard thing, especially at a scale at which we operate because there’s plenty of attractive tools and the vendors do a great job marketing and selling, especially to JPMC. I think that first and foremost is keeping track of our strategy and making sure we have that laser focus on our strategy, vision, and then how do we create that frictionless environment for developers and how is this particular tooling or solutions critical? I think it’s very important to keep that side.
Of course, being highly regulated, how secure is that solution and capabilities? There’s always plenty of tools, there’s pros and cons across the industry and especially — you refer to AI — it’s been a pretty well-known fact that AI, especially now more GenAI and LLMs, can help accelerate engineers, whether it’s coding assistance or everything else. Lori Beer, our global CIO, shared on our investor day that we are exploring what’s out there. We are exploring other opportunities, but we have to be responsible when we implement any AI strategy including what we want to do with GenAI across various applications.
It’s a very exciting space and our engineers are super excited of the potential, and I think they know more is to come in this area. Then we have this across, whether it’s securities of these ML models or whether it’s open-source security, and then the whole artifact management space even in the database space with the vector databases — there’s a lot of evolution happening. We like to innovate, so we want to look at what’s new out there so that innovation never stops. Constantly innovating, constantly learning, but what gets used in terms of production, where does the production code get used?
Are we keeping the firm safe by using that? Is it going to allow for the multiplier factor in terms of experience? That is some of the thinking that goes in before we actually take that new piece of technology and put it in for production use. 数字化转型网（www.szhzxw.cn）
本文由数字化转型网（www.szhzxw.cn）转载而成，来源于INFORMATIONWEEK.COM；编辑/翻译：数字化转型网宁檬树。
免责声明: 本网站(http://www.szhzxw.cn/)内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等) 版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
