1.
01

2.
About me
02

3.
Andrey Adamovich
Bio: Developer, coach, speaker, author
Company: Aestas/IT (http://aestasit.com)
E­mail: andrey@aestasit.com
Linkedin: http://www.linkedin.com/in/andreyadamovich
Lanyrd: http://lanyrd.com/profile/andrey­adamovich
GitHub: https://github.com/aadamovich
SO: http://stackoverflow.com/users/162792/andrey­adamovich
Twitter: @codingandrey, @aestasit
•
•
•
•
•
•
•
•
03

4.
The story
04

5.
Once upon a time...
05

6.
An email arrives...
06

7.
...let's get to work
07

8.
...two days later...
08

9.
...five days later...
09

10.
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
10

11.
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?
11

12.
No problem! We know how to write docs.
12

13.
... in the meanwhile ...
13

14.
The dreaded CR
Hey Jack, we can't deploy anymore to our DEV servers. What the hell
is going on?
14

15.
Fixing
15

16.
...things get worse...
16

17.
Worst than
down...
17

18.
UNKNOWN STATE
18

19.
Chaos (r)
19

20.
The "secret" project moves into QA
20

21.
The GO LIVE!
21

22.
Let's throw more people at it
22

23.
...it's going to work, right?
23

24.
What about
monitoring?
24

25.
Do we have
it?
25

26.
YES!
26

27.
But...
27

28.
Well...
28

29.
Sorry!
29

30.
No happy
ending?
30

31.
Where is the
problem?
31

32.
Communication problems I
32

33.
Communication problems II
33

34.
Stability vs.
agility
34

35.
Fear of deploy
Because systems are fragile, each deployment is like a trip to the
nearest casino
Devs and SysOps make development cycles longer to be as far as
possible from the deploy date
Slower time to market, systems are down more often
Nobody is happy!
•
•
•
•
35

36.
Unplanned vs. failed
36

37.
Unplanned vs. unique
37

38.
DevOps!
38

39.
Fix communication
39

40.
The feedback loop
Through configuration management and deploy automation, we can
deploy more often and reduce risk
The feedback loop gets shorter
Functionalities are rolled out with higher frequency
Systems are always in a known state
Changes to the system can be simulated and impacts calculated
•
•
•
•
•
40

41.
Sharing responsibility I
41

42.
Sharing responsibility II
The focus of DevOps is on automating the tasks performed during the
build, QA and deployment stage
The risk of deployment errors is reduced drastically by having a strong
automated testing suite, automated deployment workflow, well
defined/automated rollback process
•
•
42

43.
Reduce failed changes
43

44.
Reduce number of unique configs
44

45.
Great!
45

46.
Now we've
heard about
DevOps!46

47.
Let's do it!
47

48.
It will save us!
48

49.
Failed
expectations
49

50.
Most start
with the tools
50

51.
Tools are as
important
as...51

52.
Internal
culture!
52

53.
C.A.M.S
Culture : People over processes and tools. Software is made by and
for people.
Automation : Automation is essential for DevOps to gain quick
feedback.
Measurement : DevOps finds a specific path to measurement. Quality
and shared (or at least aligned) incentives are critical.
Sharing : Creates a culture where people share ideas, processes, and
tools.
•
•
•
•
53

54.
How Devs
and Ops can
help each
other?54

55.
TALK!
55

56.
TALK MORE!
56

57.
SHARE!
57

58.
SHARE
EVERYTHING!
58

59.
Hints for
developers
59

60.
Don't ignore
operations!
60

61.
Avoid
ShadowOps
DevOoops
•
•
61

62.
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
•
•
62

63.
Bad logging messages
63

64.
Configuration
Structure application configuration
Backward­compatibile, good defaults, good naming
Do not mix technical and business configuration
•
•
•
64

65.
Bad parameter naming
65

66.
Monitoring
Embed monitoring capabilities into your code
Know monitoring channels that your operations use: JMX, SNMP,
HTTP
•
•
66

67.
Monitoring vitals
Technical metrics:
CPU, Memory, Disk
Resource pools
Network I/O
Transactions/requests/operations per second/minute/hour
Database performance
Business metrics
•
•
•
•
•
•
•
67

68.
Create dashboards!
68

69.
Align early!
69

70.
Late alignment issues
70

71.
Learn how to use provisioning software
Puppet
Chef
Ansible
Salt
•
•
•
•
71

72.
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
•
•
•
•
•
72

73.
vagrant up
73

74.
Similarity levels
DEV << QA <<< PROD
DEV < QA < PROD
DEV ~ QA ~ PROD
DEV = QA = PROD
1.
2.
3.
4.
74

75.
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!
•
•
•
75

76.
Artifact repositories
76

77.
Automation over documentation
77

78.
Automate everything repeatable
build
release
deploy
test
backup
migration
restarts
•
•
•
•
•
•
•
78

79.
Hints for
operations
79

80.
Problem solving
Get developers to solve production problems
Look at how they did it
Post­mortem analysis
•
•
•
80

81.
Monitoring
Create dashboards! Many, but meaningful dashboards!
Analyze your data!
Create alerts!
•
•
•
81

82.
Logging
Aggregate logs
Analyze logs
Rotate logs
Clean logs
•
•
•
•
82

83.
Learn how to use provisioning software
Puppet
Chef
Ansible
Salt
•
•
•
•
83

84.
Infrastructure
as code
84

85.
Keep it in version control
85

86.
Port changes
back to DEV!
86

87.
Prepare for disaster!
Backups!
Test your backups. Seriously!
Capacity planning.
•
•
•
87

88.
Technologies
to follow
88

89.
Virtualization
Local: VirtualBox/VMWare/Parallels (+ Vagrant)
OS: Docker
Remote: Various cloud oferrings
•
•
•
89

90.
Clouds
AWS
VMWare
Azure
Google Cloud
OpenStack
•
•
•
•
•
90

91.
Infrastructure provisioning
Puppet
Chef
Ansible
Salt
•
•
•
•
91

92.
Infrastructure monitoring
Logstash
Graphite
Kibana
Grafana
Dashing
•
•
•
•
•
92

93.
DevOps companies
Spotify
Netflix
Etsy
Twitter
Amazon
Google
GitHub
•
•
•
•
•
•
•
93

94.
Reading
material
94

95.
The Phoenix Project
95

96.
Continuous Delivery
96

97.
Release It
97

98.
Inviting Disaster
98

99.
DevOps blogs
http://enterprisedevops.com/
http://itrevolution.com/devops­blog/
•
•
99

100.
Questions?
100

101.
Thank you!
101

102.
Have a nice
flight!
102