Skip to content

Instantly share code, notes, and snippets.

@phrawzty

phrawzty/notes.md

Last active September 13, 2018 09:59
Show Gist options
  • Save phrawzty/2cc426fbe341ad914cec58e149f3e4e5 to your computer and use it in GitHub Desktop.
Save phrawzty/2cc426fbe341ad914cec58e149f3e4e5 to your computer and use it in GitHub Desktop.
Download ZIP
Devopsdays Berlin 2018
Raw
notes.md

Day 2

Main track

Dirk Lehmann - Trust as Foundation of DevOps

  • TW: @doergn
  • Works at SAP
  • Background in ops.
  • Co-org Devopsdays Zurich 2019 (May)
  • SAP is a very large company distributed around the world. Everybody has their own ideas for how to "do things".
  • Each team comes up with their own processes, methods, etc; "optimising in the silo".
  • "Trust is the root of evil"
  • Trust is hard for non-philosophers to define. Wikipedia barely helps.
    • "The state of readiness for unguarded interaction withs omeor or something" Dr. Duane C. Tway Jr.
    • Capacity for trust; perception of competence; perception of intentions
  • How to measure trust? Measure speed.
    • If you see speed in an org (fast decision-making, fast execution, short times to recovery, etc), there's prob trust.
    • "The Speed of Trust" by Stephen M.R. Covey
  • How to foster trust?
    • Manage the team size. Team size has a direct impact on team communication.
      • Read: Mythical Man Month. n(n-1)/2 more people == more communications. The overhead of comm'ing becomes to heavy.
      • Robin Dunbar "Dunbar's number". Cognitive limit to the number of stable social relationships that a person can maintain. 150 people is the average limit. Many examples of 150-people groups in history, military, etc.
      • 15 "trusted friends". If the team size exceeds 15 there might be a trust problem by default.
    • Diversity is important. Humans are social creatures (even the introverts - maybe especially).
      • Henri Tajfel "simple categorisation into groups seems to be sufficient reason for people to dispense valued rewards in ways that favour in-group memebrs over those who are different".
      • Humans are hard-wired to forming groups (cliques) and gravitating to us v them mentality.
      • Don't split out the "types of work" into business units. Organise required roles within a project together.
      • Successful teams are hetergeneous
    • Ensure people feel safe. Safe spaces.
      • Embrace a "positive failure culture".
      • Many people in STEM learn about equipment failure, but not people failure.
      • Google discovered that investing in psychological safety, more than anything else, was critical to making a team work.
      • Frédéric Laloux "Reinventing Organizations": "An org cannot evolve beyond its leadership's stage of development."

Q&A

Q: What about teams that are distributed by necessity? Is video-conf enough? A: No. Necessary but insufficient. People need to physically be around each other at least a couple of times per year.

Q: How to foster trust for short-term contracts? A: What's important is having a stable core team that can on-board the temps, and keeping the total team size low. Core team maintains the long-term relationship with the project/product.

Yuwei Ren - Mentorship: From the receiving end

  • Production Engineer at Facebook
  • [email protected]
  • Talk focusing on mentoring of junior / entry-level engineers.
  • Big differences between a junior and a senior engineer.
  • Juniors are the "next generation", and mentoring is necessary to teach Ops since that's not done in school.
  • (Mentor) How to start?
    • Discuss career goal(s). Where do you see youreslf in five years? How can I help you get there?
    • Clarify your expectation(s). What do you expect from the mentee?
    • Concrete plan to achieve the goal(s). Establish milestones.
  • (Mentor) While in progress…
    • Commitment is key. Regular check-ins rather than spontaneous chat.
    • Accountability is key. Honour deadlines. Set the bar high.
    • Give constructive feedback. Avoid platitudes like "you're doing great". Be specific.
  • (Mentor) Next steps
    • Build a positive mentorship cycle. Recognise when uour mentee is ready. Encourage mentee to become a mentor or co-mentor.
  • (Mentor) What could go wrong?
    • Acknowledge that disagreements and misunderstanding are inevitable
    • Mitigate the problem before it escalates. Empathy. Listen to your mentee.
    • Unprofessional behaviour (avoid it!). Never take credit for mentee idea / output. Respect their opinion.
  • As a mentee…
    • Take responsibility for your own career development.
    • Don't be afraid to ask for help or raise questions, but try to figure it out yourself first.
    • Seek and provide feedback. Feedback cycle between mentor and mentee. Drill down for info / details.
    • Be aware of imposter syndrome.

Q&A

Q: Does there need to be organisational buy-in for a mentorship programme, or can individuals just engage in mentoring? A: Buy-in is best and formalising the process helps.

Q: How to deal with feedback that isn't all positive? A: Don't take it personally (take it professionally). Assume good intentions and learn to receive feedback. It's hard at first.

Ken Mugrage - Want to successfully adopt DevOps? Change Everything.

  • TW: kmugrage
  • Works at Thoughtworks
  • Things you need to do: redefine words, change your org, change your architecure, use CD to safely deploydeploy more often.
  • Within an org/team, agreeing on specific definitions is critical.
  • Devops is not a toolset. Not a role. Not a team.
  • Devops is verbs, not nouns. developING and operatING
  • CAMS - you need all four. Probably add the L.
  • Devops: A culture where people, regardless of title or background, work together to imagine, develop, deplouy, and operate a system. - Ken Mugrage
  • If can only change one thing to enable CALMS, change your org.
    • [Dev] | [Test] | [Ops] NOT FAIR, communication walls, etc.
    • Conway's Law - still valid. Any org that designs a system will produce a copy of the orgs communication structure.
    • Just renaming "ops team" to "devops team" doesn't work. Could be worse even.
    • Creating another silo called "devops team" has some value but isn't going to solve the problems.
    • Establish Product Teams. Werner VOgels: "You build it, you run it."
      • Put teams in direct contact with the customer.
      • "Works" is not defined as "software runs", it's defined as "providing value".
  • Use modern architectures and technologies
    • Monoliths can be hard.
    • Concentrate on developing small pieces.
    • "Microservice": an independantly deployable peice of software. If it has dependencies on other deployables, it's not a microo-service.
  • Some books: Building Evolutionary Architecutres, Building Microesrvices
  • Example of PaaS: cloud.gov
  • You can't do CD without CI.
    • "CI Theatre" describes the illusion of practicing CI but not actually doing it.
    • 90% of respondants to a survey thought that having a CI server was the same as doing CI.
    • CI according to Ken / Thoughtworks: each dev commits at least daily to a shared mainline (branches is no). Every commit triggers an aiutomated build and test. If build and test fails, it's repaired immediately.
      • Brekaing the build is not bad. Leaving it broken is bad.
    • The CD pipeline is a lot of back and forth, some serial, some parallel.
    • C delivery and C deployment are not the same thing. Delivery is a decision to deploy, deployment is an automated process to deploy.
  • Things that are bad: deplying insecure / non-performant / non-complying / ineffective software.
  • The purpose of a CD pipeline is to kill a release candidate.
    • Run tests in parallel. Those tests could be in isolated environemnts. That's ok.

Q&A

Q: Is deploying from Mainline really the only way? A: No, but it's the best way. It forces teams to communicate, work together, work on small parts, isolate components, etc.

Sponsors!

Chef

  • 10 years old now
  • New tooling for a new world: Habitat
    • Optimised for containerised envs
  • Tooling for testing, CI, CD, etc.

Google Cloud

  • 20 years old now haha
  • Hiring pitch for Munich office
  • Nice and short!

Quest

  • "We make software."
  • Started in 1980's in the US, now ~ 3500 employees "all over the world"
  • "We have devops tools."

Tiago Pascoal - Don't make the same mistakes we made in our Devops journey

  • Works at Microsoft on "azure deveops customer advisory team"
  • Product called "Azure DevOps" ? Hmm
  • Azure DevOps team has 800 people, spread out across 40 feature teams
  • Velocity increasing over time, so that's nice.
  • "Culture eats strategy for breakfast." - Peter Drucker
  • First big change: break down 40+ people "feature teams" into smaller teams of 10-12 members.
    • Everyone sits in the same room. Cross-disciplines. Self-managing.
  • Self-forming teams: people decide which teams / managers they want to work with.
    • Typically, 100% of people get a choice, but less than 20% actually change.
  • Drive by Daniel H. Pink
    • Give teams 3 things: autonomy, mastery, and purpose.
    • Intrinsic motivators better than outside
  • Alignment v Autonomy. Needs careful balance.
    • Autonomy: Plan & Practices
    • Alignment: Org, roles, teamns, cadence, taxonomy
  • Everybody works in 3-week sprints. This is not optional. If it's in master, it goes to production, so be ready.
    • Experimented with different sprint lengths, this worked best.
  • "The Stabalisation Sprint": every five sprints, do 2x sprint dedicated to stabalisation? This was a bad idea. Stopped doing it.
  • "Bug Cap": n * 5 = x where n is # of engineers, and x is max bug limit.
    • If bug count exceeds bug cap, stop working on new features and stabalise.
  • At an org level they track metrics, but NOT burndown, velocity, original estimate, completed hours, team capacity, # of bugs found.
    • Teams can track these, but not org.
    • Org only cares about impact, not activity. Are they delivering value?
  • How to stay in sync?
    • Sprint emails
      • value delivered during sprint
      • simple 5-minute video demonstrating value
      • what team is planning to accomplish next sprint
    • Team chats
      • What is plan for next three sprints?
      • Is the team healthy?
      • Any risks or issues to highlight?
    • Experience reviews
      • Storyboard of the customer experience
      • High-level execution plan (sprints, not hours)
      • Feedback!
      • Sometimes shown to key customers, not just internally.
  • Planning
    • Sprint: 3 weeks (team)
    • Plan: 3 sprints (team)
    • Season: 6 months (team & leadership)
    • Strategy 12 months (leadership)
  • Work directly from master. Non-negotiable. When sprint ends master gets deployed. Deployments can happen before that though.
    • No merging to master directly; use pull requests. PR triggers test suite, security checcks, etc.
  • PMs decide WHAT to build and WHY.
  • Engineering responsible for HOW to build and ensuring QUALITY.
  • Red / Blue security exercises.

Q&A

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment