Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Enterprise flight into DevOps space for DevOps Linz 2016

306 views

Published on

Enterprise adoption of DevOps is something that is already happening, but like with other trendy methodologies it happens quite differently with different level of success. This presentation accumulates speaker's experience in helping different size organizations to implement DevOps initiatives and gives interesting real life examples: war stories, jokes, myths.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Enterprise flight into DevOps space for DevOps Linz 2016

  1. 1. 01
  2. 2. About me 02
  3. 3. Andrey Adamovich Java/Groovy developer, clean coder DevOps guy, automation junkie Co­organizer of @latcraft and @devternity Coach at @devchampions Twitter: @codingandrey • • • • • 03
  4. 4. Enterprise! 04
  5. 5. ...or Enterprisey? 05
  6. 6. The story 06
  7. 7. Once upon a time... 07
  8. 8. An email arrives... 08
  9. 9. ...let's get to work 09
  10. 10. ...two days later... 10
  11. 11. ...five days later... 11
  12. 12. Another email Hi Jack, I got a call from Sandy, the secret project's PM, she says that the DEV servers are not ready yet, I really want you to understand how critical is this project for the organization, please, don't let me down... Francis, VP 12
  13. 13. Jack's boss Hi Jack, I understand you have been working on the secret project servers setup recently, don't forget that we need to keep the documentation up­to­date yeah? 13
  14. 14. No problem! We know how to write docs. 14
  15. 15. ... in the meanwhile ... 15
  16. 16. The dreaded CR Hey Jack, we can't deploy anymore to our DEV servers. What the hell is going on? 16
  17. 17. Fixing 17
  18. 18. ...things get worse... 18
  19. 19. Worse than down... 19
  20. 20. UNKNOWN STATE 20
  21. 21. Chaos (r) 21
  22. 22. The "secret" project moves into QA 22
  23. 23. The GO LIVE! 23
  24. 24. Let's throw more people at it 24
  25. 25. ...it's going to work, right? 25
  26. 26. What about monitoring? 26
  27. 27. Do we have it? 27
  28. 28. YES! 28
  29. 29. But... 29
  30. 30. Well... 30
  31. 31. Sorry! 31
  32. 32. No happy ending? 32
  33. 33. Where is the problem? 33
  34. 34. Communication problems I 34
  35. 35. Communication problems II 35
  36. 36. Stability vs. agility 36
  37. 37. Stagnation vs. stability? 37
  38. 38. Unplanned work 38
  39. 39. Gene Kim 39
  40. 40. Unplanned work can kill your company!40
  41. 41. Unplanned vs. failed 41
  42. 42. Unplanned vs. unique 42
  43. 43. DevOps! 43
  44. 44. Fix communication 44
  45. 45. Sharing responsibility 45
  46. 46. Reduce failed changes 46
  47. 47. Reduce number of unique configs 47
  48. 48. Great! 48
  49. 49. Now we've heard about DevOps!49
  50. 50. Let's do it! 50
  51. 51. It will save us! 51
  52. 52. But be prepared... 52
  53. 53. DevOps is highly misunderstood Your boss have heard of DevOps! Recruiters have gone crazy! All want DevOps engineers now?!? Does it mean that developers have to do everything? Natural reaction is to reject that! • • • • • 53
  54. 54. DevOps Topologies 54
  55. 55. Mathew Skelton 55
  56. 56. Anti­Types 56
  57. 57. Anti­Type A: Dev and Ops Silos 57
  58. 58. Anti­Type B: DevOps Team Silo 58
  59. 59. Anti­Type C: Dev Don't Need Ops 59
  60. 60. Anti­Type D: DevOps as Tools Team 60
  61. 61. Anti­Type E: Rebranded SysAdmin 61
  62. 62. Types 62
  63. 63. Type 1: Dev and Ops Collaboration 63
  64. 64. Type 2: Fully Shared Ops Reponsibilities 64
  65. 65. Type 3: Ops as Infrastructure­as­a­ Service 65
  66. 66. Type 4: DevOps as an External Service 66
  67. 67. Type 5: DevOps Team with an Expiry Date 67
  68. 68. Any quick hints? 68
  69. 69. TALK! 69
  70. 70. TALK MORE! 70
  71. 71. SHARE! 71
  72. 72. SHARE EVERYTHING! 72
  73. 73. Hints for Devs 73
  74. 74. Don't ignore operations! 74
  75. 75. Logging Whenever you add new logging statement to your code, remember that the guy on the other side can actually read it! Logging level, message and frequency of logging can help or disturb • • 75
  76. 76. Bad logging messages 76
  77. 77. Configuration Structure application configuration Backwards­compatible, good defaults, good naming Do not mix technical and business configuration • • • 77
  78. 78. Bad parameter naming 78
  79. 79. Monitoring Embed monitoring capabilities into your code Know monitoring channels that your operations use: JMX, SNMP, HTTP • • 79
  80. 80. Monitoring vitals Technical metrics: CPU, Memory, Disk Resource pools Network I/O Transactions/requests/operations per second/minute/hour Database performance Business metrics • • • • • • • 80
  81. 81. Create dashboards! 81
  82. 82. Align early! 82
  83. 83. Late alignment issues 83
  84. 84. Learn how to use provisioning software Puppet Chef Ansible Salt • • • • 84
  85. 85. Build a clone Same OS version, same components, same configuration as in production environemnt, but running in virtual machine on your laptop or at some cloud provider • • • • • 85
  86. 86. Package managers System administrators know how to install standard OS packages Just make one for them! RPM, DEB, MSI... ­ it's not that hard to master! • • • 86
  87. 87. Artifact repositories 87
  88. 88. Automation over documentation 88
  89. 89. Automate everything repeatable build release deploy test backup migration restarts • • • • • • • 89
  90. 90. Hints for Ops 90
  91. 91. Problem solving Get developers to solve production problems Look at how they did it Post­mortem analysis • • • 91
  92. 92. Monitoring Create dashboards! Many, but meaningful dashboards! Analyze your data! Create alerts! • • • 92
  93. 93. Logging Aggregate logs Analyze logs Rotate logs Clean logs • • • • 93
  94. 94. Learn how to use provisioning software Puppet Chef Ansible Salt • • • • 94
  95. 95. Infrastructure as code 95
  96. 96. Keep it in version control 96
  97. 97. Port changes back to DEV! 97
  98. 98. Prepare for disaster! Backups! Test your backups. Seriously! Capacity planning. • • • 98
  99. 99. Reading material 99
  100. 100. The Phoenix Project 100
  101. 101. Continuous Delivery 101
  102. 102. Release It 102
  103. 103. Inviting Disaster 103
  104. 104. DevOps blogs http://enterprisedevops.com/ http://itrevolution.com/devops­blog/ • • 104
  105. 105. Questions? 105
  106. 106. Thank you! 106
  107. 107. Have a nice flight! 107
  108. 108. 108

×