 So, today I'm going to talk about the topics about testing production. This is the emerging topic when we actually bring the DevOps into the, the DevOps culture into a company, and I actually had a sub-tuttle calling, moving the needles or driving the technical change in the, inside the company. We, as an user, not like a vendor, not like other infrastructure engineer, I would like to think of vacation development in a different perspective. As a modern application stack, we move, firstly, move minor, minor application to cloud. We actually leverage different cloud vendors to build native apps. We micro-service different back-ends. We build the SPA applications on S3 or different kind of buckets, and we also leverage CDN to talk to the audience across the world, so the application stack will change. And with that kind of mindset, we need to rethink the fail-fast philosophy, which is called to the agile process. This is very, this is the new, this is a new concept, the way to rethink the, the things existing in a different world. So DevOps actually has two camps. One is DevHat, the other one is OpsHat. With DevHat, you're actually always thinking Go Docker, Go Kubernetes, Go Service Mesh. But with the WapsHat, you always think about the CVE problems, or you think about the capacity planning, where you think about the encore issues every single day. And also, like we talked about the CSED, which I did mention last year, the CSED is just like putting what is testing efforts to shaping the products in a faster way, right? So you have unit tests in the, in the, in the round, and you have component tests, integration tests, API tests in the middle, and you have GUI tests above. Sometimes you also have manual testing to find out the bugs. When we talk about testing production, this is critical because every single piece is going to sit in one environment. But we also have DevOps tools to facilitate of the testing process as well. Because we have logging, we have monitoring, we have alerting. With those tools, these kind of a vertical can be shipping into one pyramid. So testing production is about just one environment, about every services, or every, every, everything. Because you don't need to have third-party tools to talk into your different environments. You don't need to have one dashboard to include so many different pieces. When you have problems, when you have encore issues, you don't know what is the best of metrics to communicate out. And also with this one environment, you can evolve your tests to better suit for your case, for your application development. The thing about the test is also called code needs maintenance. That actually brings the feature flags. What is the feature flag? Feature flag is about you actually have the things that you want to roll out, and the things that you don't want the users to see. It's about verging, it's about routing the logic to the right backend to the right source of truth. So feature flag 1.1 is just to have the roll out to different, for example, in our case, we have a feature text calculations to some of the countries. We need to leverage the IP address to find out that the country to determine the feature is suitable for the user or not. Sometimes you have GDPR issue that you don't want to roll out the features to the European audience until you figure out the GDPR problems. The other ones, the usage of feature flags is about cleaning the features. You have legacy code, you have modelistic applications called sitting in the backend for like 10 years, you want to kill that, but nobody in the team understand the code. So you want to put a feature flag, wrap that to make sure the code can be safe to kill. Another way to think about the feature flag is you can wrap the features depending on your use case. Sometimes the feature is around, remember sometimes the feature is around a high level member, you can also use the feature flags to do that. The Canary release is about traffic migration so that we can actually have pipeline to shift the traffic from production to the shadow traffic. The feature flag is about ten-on-ten-warf. Canary is about the pipeline work to have the testers tested against the different teams' pipeline. The final piece I want to talk about is the logs, metrics and traces. You're probably going to hear a lot in other situations, but concept-wise is logs about aggregation time series for you. The metrics is about performance, it's about testing the certain features of the function code. The traces is an easy way to pinpoint the transaction of micro-service in large picture. We also leverage traces between the front and the back end so that we can identify the issues for the users. So when we actually test in production, you need to consolidate the understanding, you need to evolve the dashboard for the better use case to find out the bottleneck. And with that, we can actually involve the practice in the long run. That's what I want to share today. Thank you.