AZ400 Exam Notes Part 1

AZ400 Exam Notes Part 1

Using the MS Ignite Challenge for this year, I am attempting to complete the AZ 400 modules to get a free exam voucher with a view to completing the exam before Christmas. Here are my notes from the MS Learn Modules

Introduction to DevOps

“DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.” - Donovan Brown

Create multidisciplinary teams that work together with shared tools and processes. Constant journey of collaboration and improvement.

Using OODA (Observe, Orient, Decide, Act) loop, its a good way to stay agile and head of competitors. Observe business, users, markets, data. Orient find options for progress. Decide on actions to pursue. Deliver

Become data-informed - 1/3 of deployments have negative effect/positive effect/no effect. Learning quickly about the effective changes means we can test and validate quickly. Shortening feedback cycles means more experiments.

Continuous Integration drives continuous merging and testing of code, resulting in early defect detection, other reduced effort fighting multiple merge issues. Plan and isolate work into sprints.

Choose the right project

DevOps processes can be applied to greenfield or brownfield projects. Common Misconception that it is only suitable for startups and new projects. Greenfield projects will have more accessible starting points, blank slate enables processes to be the desired way from the beginning. Brownfield projects have the baggage of existing code, processes, established teams and technical debt.

Organisations often use 2 modes of IT. Systems of Record provide truth about data eg Banking. Historically slow to evolve. Systems of engagement more exploratory systems based on experimentation. More of a priority for speed over precision in changes. Although engagement systems might look more appropriate for DevOps processes, both types of system can benefit greatly.

End Users need to be grouped by how excepting they are on new changes. Some of which might be incorrect causing more error prone systems. Canary: volunteer for bleeding edge features. Early adopters: volunteer for more stable preview releases. Users default users using products after they have been through other groups.

Important to roll out changes incrementally, large-scale system changes have an abysmal record of success. Find improvement goal for can be used to gain early wins, which is achievable in an acceptable time window, but has large enough benefits within the user base to be evident that the change and disruption is worth it.

For overview for the team important to agree upon and monitor appropriate KPIs for measurable goals. Commonly used KPIs could be

  • Faster Outcomes
    • Deployment Frequency - increase frequency of deployments
    • Deployment Speed - reduce time taken
    • Deployment Size - size of issues/features deployed
    • Lead Time - time between creation and completion of work
  • Efficiency
    • Server/Admin Ratio - reducing number of admins per server
    • Staff/Customer Ratio - increase customers each staff member can support
    • Application Usage - how busy is the application
    • Application Performance - Metrics from apps
  • Quality and Security
    • Deployment/App failures - how often do deployments/apps fail eg config, timeouts
    • MTR - average time to recover from failure
    • Bug reports - amount of bugs found by customers
    • Test reports - automated test runs
    • Production Defects - number of issues found in Prod
    • Availability - %age of time available
    • SLA - meeting SLAs?
    • MTD - average time to detect failure
  • Culture
    • Morale - are staff happy? periodic anonymous surveys
    • Rentention - are staff leaving?