Januar 2020 - Seite 44 von 80 - Cloud Computing Köln

We’re proud to announce the launch of Google Cloud Premium Support, which includes a robust set of services and systems to serve the enterprise and mission-critical needs of Google Cloud customers. We know that our customers need Google Cloud Support to be available in seamless, simple, and straightforward ways. We’re building upon our current technical account manager (TAM) service and 15-minute SLOs to add a more proactive approach and an improved overall experience.Premium Support has been designed to better meet the needs of our customers running modern cloud technology. And we’ve made investments to improve the customer experience, with an updated support model that is proactive, unified, centered around the customer, and flexible to meet the differing needs of their businesses. As a Premium Support customer, you’ll have your cases handled directly by context-aware experts who understand your unique application stack, architecture, and implementation details. This team will work hand-in-hand with your Technical Account Manager to deliver a customer-centric support experience with faster case resolution, more personalized service, and higher customer satisfaction. Premium Support helps bring consistency between the support plans for Google Cloud Platform and G Suite; a more competitive set of features and services; simplified pricing compared to the previous Google Cloud support offerings; intelligent systems (like third-party technology support, Support API and Recommenders); enterprise-class services; and as mentioned, customer context-aware interactions to help optimize the customer experience in Google Cloud. Here’s an overview of the Premium Support benefits:Click to enlargeWe know that our customers are running dynamic businesses and might have special projects and needs that are emerging. So, in addition to the new Premium Support, we have designed advanced services to be purchased as add-ons when needed:Advanced event management service—For deeper architecture review and increased readiness for peak events, we offer advanced event management that can be purchased separately.Expanded TAM coverage—For companies with global operations that need TAM guidance in multiple time zones, you can purchase additional TAM support during business hours in other regions.Mission-critical support—In pilot with customers and available later this year, this service offers an SRE (site reliability engineering) engagement, which evaluates and helps the customer design a wrapper of supportability around the Google Cloud customer projects that have the highest sensitivity to downtime. The process interlocks that we build with the customer allow us to jointly respond to major incidents using predefined war rooms.Premium Support is being launched now, and we’ll continue to roll out additional features and support plans through 2020. You can stay up to date on our new Cloud Customer Care portfolio.
Quelle: Google Cloud Platform

16. Januar 2020

da Agency

Using deemed SLIs to measure customer reliability

Do you own and operate a software service? If so, is your service a ”platform”? In other words, does it run and manage applications of a wide range of users and/or companies? There are both simple and complex types of platforms, all of which serve customers. One example could be Google Cloud, which provides, among other things, relatively low-level infrastructure for starting and running VM images. A higher-level example of a platform might be a blogging service that allows any customer to create and contribute to a blog, design and sell merchandise featuring pithy blog quotes, and allow readers to send tips to the blog author.If you do run a platform, it’s going to break sooner or later. Some breakages are large and easy to understand, such as no one being able to reach websites hosted on your platform while your company’s failure is frequently mentioned on social media. However, other kinds of breakage may be less obvious to you—but not to your customers. What if you’ve accidentally dropped all inbound network traffic from Kansas, for example?At Google Cloud, we follow SRE principles to ensure reliability for our systems and also customers partnered with the Customer Reliability Engineering (CRE) team. A core SRE operating principle is the use of service-level indicators (SLIs) to detect when your users start having a bad time. In this blog post, we’ll look at how to measure your platform customers’ approximate reliability using approximate SLIs, which we term “deemed SLIs.” We use these to detect low-level outages and drive the operational response.Why use deemed SLIs?CRE founder Dave Rensin noted in his SRECon 2017 talk, Reliability When Everything Is A Platform, that as a platform operator, your monitoring doesn’t decide your reliability—your customers do! The best way to get direct visibility into your customers’ reliability experience is to get them to define their own SLIs, and share those signals directly with you. That level of transparency is wonderful, but it requires active and ongoing participation from your customers. What if your customers can’t currently prioritize the time to do this?As a platform provider, you might use any number of internal monitoring metrics related to what’s happening with customer traffic. For instance, say you’re providing an API to a storage service:You may be measuring the total number of queries and number of successful responses as cumulative numeric metrics, grouped by each API function.You may also be recording the 95th percentile response latency with the same grouping, and get a good idea of how your service is doing overall by looking at the ratio of successful queries and the response latency values. If your success ratio suddenly drops from its normal value of 99% to 75%, you likely have many customers experiencing errors. Similarly, if the 95th percentile latency rises from 600ms to 1400ms, your customers are waiting much longer than normal for responses.The key insight to motivate the use of “deemed SLIs” is that metrics aggregated across all customers will miss edge cases—and your top customers are very likely to depend on those edge cases. Your top customers need to know about outages as soon as, or even before, they happen. Therefore, you most likely want to know when any of your top customers is likely to experience a problem, even if most of your customers are fine. Suppose FooCorp, one of your biggest customers, uses your storage service API to store virtual machine images:They build and write three different images every 15 minutes.The VM images are much larger than most blobs in your service. Every time one of their 10,000 virtual machines is restarted, it reads an image from the API. Therefore, their traffic rate is one write per five minutes and assuming a daily VM restart, one read per 8.6 seconds. Your overall API traffic rate is one write per second and 100 reads per second.Let’s say you roll out to your service a change that has a bug, causing very large image reads and writes, which are likely to time out and not complete. You initially don’t see any noticeable effect on your API’s overall success rate and think your platform is running just fine. FooCorp, however, is furious. Wouldn’t you like to know what just happened?Implementation of deemed SLIsThe first and foremost step is to see key metrics at the granularity of a single customer. This requires careful assessment and trade-offs. For our storage API, assuming we were originally storing two cumulative measures (success, total) and one gauge (latency) at one-minute intervals, we can measure and store three data points per minute with no problem at all. However, if we have 20,000 customers, then storing 60,000 points per minute is a very different problem. Therefore, we need to be careful in the selection of metrics for which we provide the per-customer breakdown. In some cases, it may be sensible to have per-customer breakdowns only for a subset of customers, such as those contracting for a certain level of paid support.Next, identify your top customers. “Top” could mean:invests the most money on your platform;is expected to invest the most money on your platform in the next two years;is strategic from the point of view of partnerships or publicity; or evenraises the most support cases and hence causes the greatest operational load on your team.As we mentioned, customers use your platform in different ways and as a result, have different expectations of it. To find out what your customer might regard as an outage, you need to understand in some depth what their workload really does. In some cases, the customer’s clients might automatically read data from your API every 30 minutes, and update their state if new information is available. However, even if the API is completely broken for an hour, very few customers might actually notice. To determine your deemed SLIs, consider applying your understanding of the customer’s workload from the limited selection of metrics per customer. Think about your observation of the volatility of the metrics over time, and if possible, observation of the metrics during a known customer outage. From this, pick the subset of metrics which you think best represent customer happiness. Identify the normal ranges of those metrics, and aggregate them into a dashboard view for that customer.This is why we call these metrics “deemed SLIs”—you deem them to be representative of your particular customer’s happiness, in the absence of better information. Some of the metrics you look at for your deemed SLIs of the storage service might include:Overall API success rate and latencyRead and write success rate for large objects (i.e., FooCorp’s main use case)Read latency for objects below a certain size (i.e., excluding large image read bursts so there’s a clear view of API performance for its more common read use case).The main challenges are:Lack of technical transparency into the customer’s key considerations. For instance, if you only provide TCP load balancing to your customer, you can’t observe HTTP response codes. Lack of organizational transparency—you don’t have enough understanding of the customer’s workload to be able to identify what SLIs are meaningful to them.Missing per-customer metrics. You might find that you need to know whether an API call is made internally or externally because the latter is the key representative of availability. However, this distinction isn’t captured in the existing metrics.It’s important to remember that we don’t expect these metrics to be perfect at first— these metrics are often quite inconsistent with the customer’s experience in the beginning. So how do we fix this? Simple—we iterate.Iteration when choosing deemed SLIsNow sit back and wait for a significant outage of your platform. There’s a good chance that you won’t have to wait too long, particularly if you deploy configuration changes or binary releases often.When your outage happens:Do an initial impact analysis. Look at each of your deemed SLIs, see if they indicate an outage for that customer, and feed that information to your platform leadership.Feed quantitative data into the postmortem being written for the incident. For example, “Top customer X first showed impact at 10:30 EST, reached a maximum of 30% outage at 10:50 EST, and had effectively recovered by 11:10 EST.”Reach out to those customers via your account management teams, to discover what their actual impact was.Here’s a quick reference table for what you need to do for each customer:As you gain confidence in some of the deemed SLIs, you may start to set alerts for your platform’s on-call engineers based on those SLIs going out of bounds. For each such alert, see whether it represents a material customer outage, and adjust the bounds accordingly. It’s important to note that customers can also shoot themselves in the foot and cause SLIs to go out of bounds. For example, they might cause themselves a high error rate in the API by providing an out-of-date decryption key for the blob. In this case, it’s a real outage, and your on-caller might want to know about it. There’s nothing for the on-caller to do, however—the customer has to fix it themselves. At a higher level, your product team may also be interested in these signals because there may be opportunities to design the product to guard against customers making such mistakes—or at least advise the customer when they are about to do so.If a top customer has too many “it was us, not the platform” alerts, that’s a signal to turn off the alerts until things improve. This may also indicate that your engineers should collaborate with the customer to improve their reliability on your platform.When your on-call engineer gets deemed SLI alerts from multiple customers, on the other hand, they can have a high confidence that the proximate cause is likely on the platform side.Getting started with your own deemed SLIsIn Google Cloud, some of these metrics are exposed to customers directly through project-related, Transparent SLIs.If you run a platform, you need to know what your customers are experiencing.Knowing that a top customer has started having a problem before they phone your support hotline shrinks incident detection by many minutes, reduces the overall impact of the outage, and improves relationships with that customer. Knowing that several top customers have started to have problems can even be used to signal that a recent deployment should presumptively be rolled back, just in case.Knowing roughly how many customers are affected by an outage is a very helpful signal for incident triage—is this outage minor, significant, or huge? Whatever your business, you know who your most important customers are. This week, go and look at the monitoring of your top three customers. Identify a “deemed SLI” for each of them, measure it in your monitoring system, and set up an automated alert for when those SLIs go squirrelly. You can tune your SLI selection and alert thresholds over the next few weeks, but right now, you are in tune with your top three customers’ experience on your platform. Isn’t that great? Learn more about SLIs and other SRE practices from previous blog posts and the online Site Reliability Workbook.Thanks to additional contributions from Anna Emmerson, Matt Brown, Christine Cignoli and Jessie Yang.
Quelle: Google Cloud Platform

16. Januar 2020

da Agency

New Azure blueprint for CIS Benchmark

We’ve released our newest Azure blueprint that maps to another key industry-standard, the Center for Internet Security (CIS) Microsoft Azure Foundations Benchmark. This follows the recent announcement of our Azure blueprint for FedRAMP moderate and adds to the growing list of Azure blueprints for regulatory compliance, which now includes ISO 27001, NIST SP 800-53, PCI-DSS, UK OFFICIAL, UK NHS, and IRS 1075.

Azure Blueprints is a free service that enables cloud architects and central information technology groups to define a set of Azure resources that implements and adheres to an organization's standards, patterns, and requirements. Azure Blueprints makes it possible for development teams to rapidly build and stand up new trusted environments within organizational compliance requirements. Customers can apply the new CIS Microsoft Azure Foundations Benchmark blueprint to new subscriptions as well as existing environments.

CIS benchmarks are configuration baselines and best practices for securely configuring a system developed by CIS, a nonprofit entity whose mission is to ”identify, develop, validate, promote, and sustain best practice solutions for cyber defense.” A global community collaborates in a consensus-based process to develop these internationally recognized security standards for defending IT systems and data against cyberattacks. Used by thousands of businesses, they offer prescriptive guidance for establishing a secure baseline system configuration. System and application administrators, security specialists, and others who develop solutions using Microsoft products and services can use these best practices to assess and improve the security of their applications.

Each of the CIS Microsoft Azure Foundations Benchmark recommendations are mapped to one or more of the 20 CIS Controls that were developed to help organizations improve their cyber defense. The blueprint assigns Azure Policy definitions to help customers assess their compliance with the recommendations. Major elements of all nine sections of the recommendations from the CIS Microsoft Azure Foundation Benchmark v1.1.0 include:

Identity and Access Management (1.0)

Assigns Azure Policy definitions that help you monitor when multi-factor authentication isn't enabled on privileged Azure Active Directory accounts.
Assigns an Azure Policy definition that helps you monitor when multi-factor authentication isn't enabled on non-privileged Azure Active Directory accounts.
Assigns Azure Policy definitions that help you monitor for guest accounts and custom subscription roles that may need to be removed.

Security Center (2.0)

Assigns Azure Policy definitions that help you monitor networks and virtual machines where the Security Center standard tier isn't enabled.
Assigns Azure Policy definitions that helps you ensure that virtual machines are monitored for vulnerabilities and remediated, endpoint protection is enabled, system updates are installed on virtual machines.
Assigns an Azure Policy definition that helps you ensure virtual machine disks are encrypted.

Storage Accounts (3.0)

Assigns an Azure Policy definition that helps you monitor storage accounts that allow insecure connections.
Assigns an Azure Policy definition that helps you monitor storage accounts that allow unrestricted access.
Assigns an Azure Policy definition that helps you monitor storage accounts that don't allow access from trusted Microsoft services.

Database Services (4.0)

Assigns an Azure Policy definition that helps ensure SQL Server auditing is enabled as well as properly configured, and logs are retained for at least 90 days.
Assigns an Azure Policy definition that helps you ensure advanced data security notifications are properly enabled.
Assigns an Azure Policy definition that helps you ensure that SQL Servers are configured for encryption and other security settings.

Logging and Monitoring (5.0)

Assigns Azure Policy definitions that help you ensure a log profile exists and is properly configured for all Azure subscriptions, and activity logs are retained for at least one year.

Networking (6.0)

Assigns an Azure Policy definition that helps you ensure Network Watcher is enabled for all regions where resources are deployed.

Virtual Machines (7.0)

Assigns an Azure Policy definition that helps you ensure disk encryption is enabled on virtual machines.
Assigns an Azure Policy definition that helps you ensure that only approved virtual machine extensions are installed.
Assigns Azure Policy definitions that help you ensure that system updates are installed, and endpoint protection is enabled on virtual machines.

Other Security Considerations (8.0)

Assigns an Azure Policy definition that helps you ensure that key vault objects are recoverable in the case of accidental deletion.
Assigns an Azure Policy definition that helps you ensure role-based access control is used to managed permissions in Kubernetes service clusters

AppService (9.0)

Assigns an Azure Policy definition that helps you ensure web applications are accessible only over secure connections.
Assigns Azure Policy definitions that help you ensure web applications are only accessible using HTTPS, use the latest version of TLS encryption, and are only reachable by clients with valid certificates.
Assigns Azure Policy definitions to ensure that .Net Framework, PHP, Python, Java, and HTTP versions are the latest.

Azure customers seeking to implement compliance with CIS Benchmarks should note that although this Azure Blueprint may help customers assess compliance with particular configuration recommendations, it does not ensure full compliance with all requirements of the CIS Benchmark and CIS Controls. In addition, recommendations are associated with one or more Azure Policy definitions, and the compliance standard includes recommendations that aren't addressed by any Azure Policy definitions in blueprints at this time. Therefore, compliance in Azure Policy will only consist of a partial view of your overall compliance status. Customers are ultimately responsible for meeting the compliance requirements applicable to their environments and must determine for themselves whether particular information helps meet their compliance needs.

Learn more about the CIS Microsoft Azure Foundation Benchmark blueprint in our documentation.
Quelle: Azure