Home - mihirvijdeshpande/devops GitHub Wiki

Welcome to the DevOps Quest!

Lets understand the plot to begin: What is DevOps? Defination :- The practice of Operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.

    Development          +         Operations
 * Developers                   * System Admins
 * Front end                    * Network Admins
 * QA                           * Database admins

CALMS (Culture Automation Lean Measurement and Sharing) <- These are the core entities which are targeted to build the foundation of Good DevOps team build-up Culture needs a change from having distinct teams passing on the ball of responsibiliities over a wall creating a communication gap. Automation needs to get embedded into the gaps of human handled tasks to not loose time in tranistions. Leans needs to be applied to cutoff unneccessary/ dead / lossful parts of process. Measurement needs to be reevaluated as in what parameters are keeping track of progress. Sharing needs to have dedicated channel between teams with all possible feedback loops for alerts and making all teams aware of what one team is doing.

There are various methodologies that play crucial role in building up efficient DevOps team.

Methodologies:

  1. People over process over tools :-
  • Identifies who is responsible for a job function first
  • Then defines the process happened around them
  • Then determining and implementing the tools to perform that process
  1. Continuous Delivery :- Practice of coding, testing and releasing software frequently in small batches to improve the overall quality and velocity.

  2. LEAN management :-

  • Work in small batches
  • Work in progress limits
  • Feedback Loops
  • Visualization
  1. Visible Ops-style Change control :-
  • Eliminate fragile artifacts
  • Create a repeatable build process
  • Manage Dependencies
  • Create an environment of continuos improvement
  1. Infrastructure as Code :-
  • System treated like code
  • Checked into source control
  • Reviewed, built, and tested
  • Manage programatically

The need to transition to DevOps - The wall problem

Developers and Operations have a wall in between them in traditional approach. Developers are accountable for -- New functionality, Making Changes, Moving fast. Operations are accountable for -- Maintaining stability, Controlling change.

Also development teams are at least usually organized by a business sector or an application, infrastructure teams are often organized by technology stack that involves more teams to the picture adding more walls. The setup of 2/3 teams gets a little more complicated with 6-8 teams. Having all of them discussing this out will cause issue. Rarely because of malicious intent but more often due to conflicting goals or lack of context about other team's work. There is an approach that can be followed the resolve this

  • THe blameless postmortem
    • Do it within 24/48 hours of incident
    • Have the team build a timeline
    • Have a third party run the meeting who has neutral perspective

The actual blpm runs should progress with this checklist

  • Description of the incident
  • Description of the root cause
  • How the fix was implemented
  • Timeline of events and actions taken
  • How customers were affected
  • Remedy plan and quicker corrections

After the postmortem We need to communicate this to stakeholders

  1. Admit failure
  2. Sound like a human
  3. Have a communication channel
  4. Be Authentic

Processes are sidewheels that need to drop off as the company matures The management best practices that were observed to go well with DevOps implementations are

  • reorganizing into independent cross functional teams,
  • understanding the fears people have that are barriers to change, and helping them through it.
  • And using lean agile processes to keep your effort focused on value creation.

Building Blocks of DevOps

  • Agile : Manifesto for Agile Software Development values more
    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan Both sides are valued, just the left side is valued more than right side

Its missing mention of Operations, the last part of software delivery pipeline where the infrastructure is built and the apps are deployed and maintained in production. May be that's why it was seen as a threat by Infrastructure side of the IT orgs. However, once operations is onboard to this extension of Agile it is quite promising with the involvement of LEAN practice.

  • LEAN : Systematic process to eliminate waste in brief 7 principle of LEAN
    • Eliminate waste. : Muda (Work that absorbs resources but adds no value), Muri (Unreasonable work imposed on workers and machines), Mura (Work coming in unevely instead of a constant or a regular flow)
    • Amplify Learning.
    • Decide as late as possible
    • Decide as fast as possible
    • Empower the team.
    • Build in integrity.
    • See the whole.

Similar to the just-in-time credo of lean manufacturing and aligned with the agile idea of being flexible, you try to move fast but delay decisions in enhanced feedback loops and group context. This works with keeping integrity in check while keeping an eye on the big picture.

  • ITIL, ITSM and SDLC : The tradional approach of IT service management that is defines the units of process starting from Planning, designing and upto maintainance and retirement. These are still import in DevOps being the block of units placed coupled with Agile and LEAN.

Infrastructure Automation

  • IoC: Infrastructure as a Code A completely programatic approach to 'codify' the infrastructure with automating tasks that shouldn't need human intervention and face chances of manual failure. Just like a code has its script to perform the task its created to perform, Infrasture's template is created which has all levels of automation for all the components and the configuration needed to be performed. In IoC thought process, we should be able to utilize tools that can make up a server bottom up from bare metal to conmpletely set for production in a totally programmable approach. It should also then allow modification as well deletion of components as well as the whole infrasture.

  • Configuration Management:

  • Provisioning : Making server ready for operation, including hardware, OS, system services, and network connectivity.
  • Deployment : Automatically deploying and upgrading applications on a server.
  • Orchestration : Performing coordinated operations across multiple systems.

Management of change control system for system configuration after initial provision; maintaining and upgrading the application and its dependencies.