DevOps

Week 1

DevOps breaks down all barriers and  get everyone collaborating from get-go on the Same team.
DevOps is about people and it is about creating a culture of focusing on delivering value for custo er.
CAMS- Culture, Automation, Measurement, Sharing
CALMS - ...,...,Lean,...,...

DevOps Principles: Three Ways

• System thinking, sistemi bütün olarak anlayıp iyileştirmeye calismak
• Amplifying feedback loops, suanki durumu anlayıp sonraki adımı daha hızlı geliştirmek, yazılımcilara daha çabuk feedback dönmesi için otomatik test yazmak mesela
• Creating culture of continuous experimentation and learning

Figuring out how to protect capacity, haber the capacity to focus on activities that are above and beyond feature delivery. Büyük org en büyük yaşadığı zorluk.

DevOps Principles: Seven Principles and Wastes of Lean

• Eliminate Waste
• Build Quality In, küçük batchler halinde kod yaz, test et ve hata varsa hemen düzelt
• Create Knowledge
• Defer Commitment, sonradan aldığın kararlari degistirme, zaman kaybı, elinde az bilgi varken karar verme. Birkaç seçeneğin olsun, ilki fail ederse diğerleriyle devam edersin. 
• Deliver Fast
• Respect People
• Optimizing Whole

Seven Wastes

• Extra Features, müşterinin istemediği birşeyi yapma
• Handoffs, işi başkasına verme
• Partially Done Work
• Revisiting Decisions
• Delays
• Task Switching/Multitasking
• Defects

Improvement Kata Principles

Improvement Kata comes from production system and it allows You to continuously improve.

• Understand vision and direction of project
• Analyze to understand current condition
• Establish Target condition
• Plan,Do,Check,Act toward target(Deming's Cycle)

A3 Problem Solving Framework

A3 Steps-Deming's Cycle

• Background, Problem Statement/Current Condition, Goal/Target Condition, Analysis-Plan
• Proposed Countermeasures-Do
• Implementation Plan - Check
• Followup Actions - Act

Step 1:Set the Background
This should include a Statement of how problem directly impacts business outcomes.
Step 2:Current Condition and Problem Statement
Current reality:where things standart today
You would be able to tie this listesi revenue ör another metric.
Step 3:Develop Goal/Target
Target state You are trying to achieve
Explain how You will measure outcome
Step 4: Performance Analysis/Root Cause Analysis
İdentify Root cause
En çok zamanı bu aşamalara ayirmak gerekiyor. Bu kısmi düzgün yapan daha başarılı oluyor ama çoğu grup Do kısmına geçmek istiyormuş.

Proposed Countermeasures:
Step 5:Brainstorm
Determine some potential Countermeasures that You introduce to experiment and attempt to solve the problem. This should include how You intend to reach the target, meaning a hypothesis on how Countermeasures could help to reach Target.

Step 6: Implementation Plan
Enables You to Check results
Confirms impact on Current Condition
Mesela iki haftada 10tane otomasyon scrpti yazılacak. Ataması Qa managera yapılacak.

Followup Actions
Step 7:Update
Update "standard Work" based on steps taken

Westrum Model

Model that is used in DevOps.

Topology of Organizational Cultures

1. Pathalogical/Power-Oriented:Large amounts of fear and threat
2. Bureaucratic: Rule-oriented
3. Generative:Performance oriented

Organizational Culture predicts information flow: 3 Characteristics of Good Info

Answers provided, timeliness, presented in suac a way to ne effective

Organizational Culture predicts Performance Outcomes: Data shows that cukture predicts software delivery Performance 

Output/Outcome

Output eline geçen herhangi bir şey, ürün vs. Outcome ondan elde ettiğin fayda.

Week 2

The Importance of Loosely Coupled Architecture Teams

Tightly Coupled Architecture, bileşenlerin birbirine çok bağımlı olduğu mimariler. Birinde değişiklik yapıldığında hepsinde değişiklik yapmak gerekir. Loosely coupled architecture DevOps a daha uygun. Bileşenler izole edilebilir, bağımsız şekilde değiştirilip test edilebilir, değişiklikler hemen uygulanabilir ve bunlara rağmen halen bütünün bir parçası olabilir.

Faydaları: horizontal olarak boyutlandırılabilir, testi kolaylaştırır, hız ve agility e izin verir

The Importance of Iteration and Evolution of Roles

İlk önce çalışıp çalışmayanı bul ve sonra bütün org yana yay. Bunun için pilot deneme ve A/B testi yapabilirsin. 

Küçük başla, hemen geri bildirim al, hızlı öğren ve uygula. Zaman, para ve efordan kazanırsın.

Entegre takımın faydası: Proaktif, hızlı geri bildirim alınır, testten önce kod düzeltilir.

Product Owner Role: Business system analistlerinin ürün owner role unda olmasına izin ver, dev teamin içinde. 

Evolution of Dev: Dev/Eng zhniyeti dev, quality, secuirty ve non-functional gereksinimlerden de sorumlu olmasını sağla. Büyük resmi görmelerini sağla.

Bütün rolleri bir takıma verebilirsin. CI/CD pipeline ları beraber oluşturabilirler...

Managing Risk with DevOps

MTTR Mean Time To Restore service düşük olmalı.

Freeze Windows, yoğun zamanlarda(sistemin yoğun kullanım zamanlarında) ekranların değiştirilmesinin yasak olması

CICD, Continuous Integration and Continuous Delivery. Küçük batch halinde kodu deploy ediyorsun böylelikle hata riskin az oluyor. Bu freeze windows a uygun bir çözüm olarak sunuluyor DevOpsta. Hem müşterinin ihtiyacı olan yenilemeyi/değişikliği de hemen ulaştırıyorsun.

Dealing with Unplanned Work

Planlanmamış iş, sorulan soru olabilir, bir incident olabilir ya da herşeyi bıraktıran bir olay olabilir . Planlanmayan olay başına geldiğinde onu takip et, ne kadar zarar verdiğini bul. Bütün org. un performansını etkileyebilir. Böylelikle planlama yaparken unplanned work için de bir zaman/maliyet ayırabilirsin.
Context Switching: Multi-tasking. Zaman kaybı, kalite kaybı oluşabilir.
Birden fazla önceliğin olsun ve bu öncelikleri dağıt. Karışıklık olduğunda senior liderler çözsün. Açık ve net olsun öncelikler. Stratejik olanlar daha öncelikli olmalı.
Integrated Environment: Birçok bağımsız servisin birlikte deploy edildiği environment.

Managing Workload with a DevOps Mindset

Bir sorunu çözmenin en iyi yolu: Onu görselleştir ve business outcome ile bağlantısını göster.

Takımların bütün  ürünü build, own ve improve etmelerini sağla. 

eNPS: Çalışanların yaptıkları işten memnun kalmalarını ve başkalarına da önermeleri.

Çalışan ne kadar mutluysa o kadar iyi iş çıkarır.

Making Work Visible

Kanban, Trello, Jira gibi araçlar kullan. Şimdiki durumunu, trendleri, hedefleri bu araçlarla görebilirsin. İyileştirme kararlarını bunlardaki bilgilerle alabilirsin. Unplanned work ü görebilirsin.

Daha küçük parçalara bölünmesi gereken işleri görebilirsin. Soru sormaya fırsat verir. 

Work in Process

WIP(work in process) limiti koy. Görsellerle destekle. Dev takımına feedback ver. 

WIP: Bir kere de belli miktarda iş yapmanı sağlar. Elindeki iş bitmeden yenisine geçemezsin.

5 thieves of time: Too much work-in-process, conflicting priorities, unknown dependencies, unplanned work, neglected work

Week 3

Work is Work

Dev ve operation grubunu tek backlog a koy. Önceliklendirme yap ve yapılan işlerle ilgili ölçüm yap. Herkes birbirine yardım etsin. Hızı ve kaliteyi artırır. 

Ölçüm için MTTR, MTTD, incidents, error rates, response times vs kullanabilirsin.

Monitoring with DevOps Mindset

MTTD: Mean Time To Detect, otomatize edilmiş alarmlar sorunun saniyeler içinde çözülmesini sağlar.

Using Incident Reviews to Your Advantage

Blameless Incident Reviews: Encourage candor(samimiyet) and learning, perform critical and objective analysis, plan prevention strategies for future

Honoring and Extracting Reality: Seek discovery of what really happened, It has to be safe for reality to surface, If leaders do not want to understand thet will not be able to extract reality

Westrum Modelde:

1. Pathalogical/Power-Oriented: Failure>Blame&Scapegoating(günah keçisi olarak görmek
2. Generative:Performance oriented: Failure>Inquiry Spirit of learning, blame-free

Transformation of Root Cause Analysis: with complex systems we must seek multiple contributing factors

Human errors are never the root cause, something in the system broke down, usually it is a process failure

Software industry has evolved with regard to incident management

Shift from seeking a single root cause to multiple contributing factors

High-performing organizations use incidents as opportunities to learn

Focus on what broke down in the system, NOT human error

Organizational Models in DevOps: Functional Silo Structure

DevOps in and of itself is not an organizational structure. 

Rather it defines;

• away to organize independent teams cross-functional or full stack.
• a culture humane and outcome-based. 
• a set of lean principles.
• fast feedback including feedback from production. 
• a set of practices highly-automated with continuous delivery. 

Continuously refine what works for your org: use agile approach to find org structure, use the Plan>Do>Check>Act loop, all org models have pros/cons

To be high-performing, teams must have skills in development, 

testing, operations, and security at the very least. 

Working in such cross-functional teams avoids handoffs and increases the possibilities for rapid feedback, not only from testers and users of the product but also from the actual usage of the system in production. There is clearly a tension between the DevOps cross-functional approach and the traditional functional silo-based approach. Rather than asking whether DevOps can be made to fit within traditional organizational structures, it might be better to ask, what characteristics an organizational structure would 

need to have in order to align with the DevOps model? It's also important to know what outcomes the organization is trying to achieve. If optimizing for speed or cost?

Organizational Models in DevOps: Seven Characteristics

The first characteristic for a model, is that the organizational structure must support and promote the mechanics of the DevOps approach and its goals. As a type of Lean process, DevOps focuses on shortening lead times and generating rapid feedback. In evaluating an organizational structure, 

we must ask ourselves whether it is likely to deliver on these objectives. Are there barriers to rapid delivery? For example, are there difficult handoffs between different groups? Are there required sign offs or approvals that will result in wait time between major processes? Is the flow of feedback frictionless or does it need to go through appropriate channels? Can teams be autonomous and empowered? Or will their goals conflict with those of the hierarchy that they are a part of?

Secondly, the organization must also encourage communication and the free flow of information, in general this means that communication should be face-to-face and ad-hoc, rather than through formal documentation. Silos for example, tend to encourage communication within the silo, but are rarely effective at establishing lines of communication between silos. Sometimes it's not unlike high school clicks that remain insular, and choose not to interact with other groups.So, whether or not the organization's hierarchy encourages communication between silos to accomplish the goals of DevOps must be evaluated.
Third, the organizational structure must share accountabilities to support the goals of delivering high quality impactful software. DevOps requires empowered teams, which in turn requires that the teams be given responsibility of a goal. You should ask yourself, does the organizational structure allow meaningful goals to be passed down through the structure, so that teams can own their delivery? 

Do you have a way to measure and understand how many handoffs occur as teams are trying to deliver value? Do have approval processes or gates, that impact the flow of value?Answering these questions and analyzing the current state of how software is delivered coupled with a lining on organizational objectives, will help you understand if a structure or organizational change will be needed.

The fourth characteristic we should look at involves, evaluating the mechanisms related to risk mitigation compliance, and auditability. Does the organizational structure established the controls required by the company's compliance activities? For example, SOX, HIPAA, PCI, GDPR. While at the same time providing the flexibility and empowerment for the DevOps teams to succeed.Often, organizations operate with compliance and security teams separate from the development and operations teams. In a DevOps minded culture, the compliance and security requirements actually become a part of the product and the delivery teams. In functional silo organizations, it can often be difficult to overcome the perceived risk management of keeping these teams and activities separate. However, high-performing organizations have security built-in and automated within their pipelines.

The fifth characteristic to consider, is how the organization allows for humane and fair distribution of burdens. DevOps is based on the idea that a development team should not toss its product over the wall to an operations team, which then must deal with the operational consequences. Nor, should an operations team so constrained development, that it is unable to meet the goals of its users. 

This principle really should apply to the organization as a whole, our responsibilities must be distributed such that no group has an unsustainable burden. This helps mitigate employee and team burnout, 

it's really a way of asking whether the entire organization is motivated by a shared goal, 

which is ideal, or by conflicting goals which is not. This concept is also described as, 

you build it, you own it, you improve it.
Sixth, the organizational structure should recognize, and value the voice of the individuals. 

DevOps and other Lean practices seek to empower those closest to the action to use their own judgment, does the structure require that individuals get layers of approval to take action? Or is it flattened in a way that encourages interaction between managers and individual contributors? Do individuals have a voice in decisions? Is there feedback regularly solicited?
Seventh and finally, the organization must be flexible enough to support continuous improvement, 

can the organization easily reconfigure itself based on what they've learned from feedback loops and shared experience? The structure of the organization is not the only factor that encourages the seven positive characteristics, but it certainly can be an obstacle. With these characteristics in hand, 

we can examine some organizational structures and the degree to which they helped deliver efficiency and productivity.

Organizational Models in DevOps: Matrix, Embedded, Full Stack Cross, Functional Structures

A matrix structure is when functional areas will have a dotted line, 

essentially representing informal reporting relationships to product teams. 

I've seen this model in all three companies I've worked for. 

Often, it is used when it does not make sense to 

dedicate a person to a team for the particular skill they have. 

For example, I've supported teams that had products with Oracle databases and 

the Oracle DBA team was not big enough to embed or 

dedicate database administrators to every product team. 

Instead, they maintained a dotted line relationship 

and work closely with the teams when needed. 

This allowed them to continue to optimize for efficiency across the organization. 

Now, this model can be challenging if multiple products 

require the same skillset and that skill set is scarce. 

Often, this can lead to disagreement about priority. 

In this model, it is important to have a way to reconcile and provide clarity, 

if competing priorities surface. 

Without that structure, the team will be left to decide and that can often lead to 

paralysis or making a decision that is 

not truly aligned with the organization's objectives.

One way to help mitigate this is to move to more of an embedded model. 

This model keeps the reporting relationships as is and 

dedicates people from the functional areas to the product teams. 

To address what I mentioned about not having enough people, 

I've tried the embedded model, 

by prioritizing products that needed the embedded people the most. 

For example, if we were working on 

a strategic priority requiring wireless network expertise, 

then we would embed a wireless network engineer 

in that product team only, not everywhere. 

Other products dependent on wireless network engineers would remain in the Matrix Model

The second structure is called a Product and Platform Structure. 

This is sometimes also referred to as a Full-Stack. 

A product structure has teams dedicated to individual products or product groups. 

They are supported or enabled by a group that maintains 

the platform on which they work and often additional groups for tool support, 

help desk, and end-user services. 

Their activities are informed by groups dedicated 

to the voice of the customer and product strategy. 

Organizations vary on how they define what belongs in the platform organization.

Platforms in this definition, 

includes content management, digital asset management, 

search, checkout, payment, inventory, 

login, profile, and consumer data. 

In my case, we are treating our platforms as products, 

creating simplified ways for other teams to consume the platforms and APIs. 

One drawback with the product and platform structure, 

is that it can be challenging to adapt. 

If a product starts to become more of a steady-state investment, 

how do you evolve the team dynamics to support that? 

If you need to create a new product team, 

do you mobilize with key people from other product teams? 

Or do you create the team with all new team members? 

If you pull people from other product teams, 

how do you minimize disruption to the product they are currently working on? 

Here's where the third common structure comes into play. 

It is an adaptive structure. 

It's organic and dynamic, 

adjusting and reconfiguring itself as needed. 

In its purest form such an organizational structure would be completely flat, 

to the extent that management remains, say a CIO. 

The focus would be much less on control and decision-making than more traditional models. 

Instead, management would focus on vision, culture and people. 

The product of management in such an organization is learning.

Product teams take accountability and responsibility for setting their mission, 

staying aligned, and delivering value to customers and other stakeholders. 

This model contains the capability to generate and retire 

new structures to meet real-time needs from stakeholders as the organization learns. 

The structure of such an organization is fundamentally different from the prior models

A change in structure such as moving from

functional silos straight to a product structure, 

effectively bypassing a Matrix Model, 

could in some contexts help achieve 

a profound alignment to DevOps principles and practices. 

At the end of the day however, 

there is no default answer to the question, 

"What model is best for my organization?" 

Invariably it depends.

Week 4

Using Feedback Loops to Improve Development Speed

One common example is to build quality into the product early, 

so developers can get immediate feedback on the product.

Often, this is done through automation, 

and gets away from the old way of delivering 

the product through handoffs to a quality assurance team.

A core principle of DevOps is building quality in. 

This is also a key principle at the heart of continuous delivery.

shorter product lead times are better, 

since they enable faster feedback on what you're building, 

which in turn allow us to course-correct and ultimately learn more rapidly. 

Short lead times are also important when there is a defect or outage, 

and we need to deliver a fixed rapidly and with 

high confidence to avoid significant downtime. 

Another metric to consider is batch size. 

Reducing batch size is another way to accelerate feedback. 

just know that breaking down work into 

something small is a great way to improve feedback loops. 

The smaller the change, 

the easier it is to know what impacts that change creates. 

In traditional software delivery,

when deployment frequency is low, often, 

the delivery of features is a long list, 

and it can be really hard to understand what's impacting what, 

and how to recover if an incident occurs.

Another strategy to use, is A/B testing. 

If you're unfamiliar with the term, 

it refers to the idea of testing two different approaches to 

doing something presented randomly to end-users. 

It's extremely important as you start to deliver more digital solutions. 

Old methods for getting feedback are hard to scale. 

We could experiment with two different experiences, 

and let the customer feedback help us decide which one to implement. 

Building quality in enables developers to get feedback early and often. 

A/B testing allows for experimentation and feedback from customers at scale. 

Breaking work down into the smallest increment 

as possible is another way to get fast feedback. 

Ultimately, you're trying to speed up decision-making and mobilization. 

Focusing on speed will create the best opportunities to learn.

Leveraging Feature Branches

In order to build quality in, 

the aim would be to incorporate security tests 

early in the deployment pipeline to help avoid late feedback. 

Teams can address issues early and security teams can 

also feel confident that the tasks are automated and documented. 

The second principle is to work in small batches. Delivers measurable outcomes quickly, focus on a small part of target market, get essential feedback to course correct, lowers cost of pushing out individual changes

Computers perform repetitive tasks, people solve problems: reduce cost of pushing out chnages, automate repetitive work, free people up for problem-solving

Relentlessly pursue cont inp: insanlara zaman kaldıkça daha zorlu işleri başarmak isterler, işlerini mükemmeleştirmeye çalışırlar

everyone is responsible: collaboration, outcomes should be transparent, set measurable, achievable, time-bound goals for outcomes, help teams work toward these goals

Conf Manag, CI, Testing and Delivery

Start transformation: start with understanding, let vsm inform decisions, then look at automation and tooling

Employ Comprhensive Conf Mang: to implement cd, use an automated process for version control, even with manual approvals, apply all changes automatically

CI: work in small batches and build quality in, keep branches short-lives and integrate them into trunk frequently, the first priority is to solve problem

Cont testing: testing should be ongoing in dev process, run automated unit and acceptance tests against every commit to version control, this gives dev fast feedback on their changes

Bütün testler koşmalı, hatalar düzeltilmeli, keşifsel test de yapılmalı

CD: releasing new versions should be routine, can be performed on demand at anytime, requires collaboration across teams

Value Stream Mapping and Continuous Flow

It helps identify constraints limiting your ability to deliver value to cstomers. A fact-based way to show how value flows through the org, used to get current cond of cycle time and/or lead time

Steps:suanki durumu adım adım yaz

her adımın ne kadar sürdüğünü tahmin et

gereksiz adımları kaldırarak/ zamanları azaltarak yeni adımları yaz

Bunu yaparken faydası olabilecek herkesi çağır

sorunları çözmene, effor/zaman kayıplarını engellemene, şimdiki lead/cycle tşme ını analiz etmene yarar.

lead time: işin alımından ürünün müşteriye ulaşma anına kadar geçen süre

cycle time:bir dev in bir feature için çalışmaya başladığı zamandan ürüne deploy edildiği ana kadar geçen süre

İlk önce cycle time dan başla, yapılan işi herkes için görselleştir.

Shifting from Big Batch to Small Batch

MVP stands for Minimum viable Product and is defined as a product 

with enough features to satisfy 

the initial customers and provide feedback for future development. Sadece müşterinin gereksinimi içeren ürünü yapıp test ediyorsun. Hızlı feeedback alıp eğer müşteri memnunsa bununla devam ediyorsun.

Working in the smaller batch approach gives faster feedback 

and lowers the risk of deployment and recovery from failure. 

High-performing organizations slice up products and features into small batches that can 

be completed in less than a week and released frequently including the use of MVPs

Reducing batch size is another central element of the Lean paradigm. 

Reducing batch sizes reduces cycle times and variability in flow, accelerates feedback, 

reduces risk and overhead, improves the efficiency, 

increases motivation and urgency, 

and reduces costs and minimize schedule impacts.

However, in software, batch size is hard to measure and 

hard to communicate across contexts as there is no visible inventory. 

Deployment frequency can be used as a proxy for batch size, 

because often if you are delivering in small batch, 

you are delivering more frequently. 

An MVP is a prototype of a product with 

just enough features to enable validated learning and the product and its business model. 

Working in small batches enables short lead times and faster feedback loops.

Speed Does Not Mean Low Quality

stability+speed = quality

low quality = slower and more rework

cok test yapmak kaliteyi artırmaz

deploy sıklığı versiyon kontrolü ve cd ile bağımlı

lead time vers control ve otomasyon testiyle bağımlı

mean time vers control ve izleme ile bağımlı

versiyon kontrolü yap, handoff u bitir, şeffaf ol ve doğru metrikleri ölç. hızlı şekilde dploy etmek için MTTR yi düşür