job at ntt.net
Wed Jun 14 20:16:45 CST 2017
The talk was giving in context of motivating people to start with
network automation and help them go from 'no automation' to a step
further 'some automation'.
On Wed, Jun 14, 2017 at 07:50:05PM +0000, Graham Johnston wrote:
> Would you be able to provide any further insight into your Don’t #5 –
> “Don’t agree to change management.
I think the development team of the network automation software should
define their own process around change management. If you want to use
kanban? great! if you want to use simple fifo model applied to issues
filed on your private github project? great! My point was: don't let
someone from higher up dictate how, and when you do software releases.
Another aspect is that you most likely will have proceses that should
run without any human intervention: such as the nightly update for all
EBGP prefix-filters. You don't want to end up in a situation where a
computer generates those configs and has to hand them over to a human
for some additional checks and subsequently pushing it out to the
network. Imagine having the computer print out your automatically
generated configs, a human pick them up, review them, and type them back
into a computer for the changes to take effect! That would be terrible.
> Managers are rarely engineers and should not be making technical
> decisions. (nor should sales)“.
That was a simple point: ideally a manager enables you to do your work,
and trusts you to do the work. If you have a manager who opinionatedly
argues with you on tabs vs spaces or how to push a configuration to a
device, you might find that you don't have enough freedom of movement to
succesfully bootstrap the automation project.
In other words: don't roll over and blindly accept what other
(inexperienced) folks within the organisation tell you, try to find your
own path. However, do make sure you steal the good ideas from the
sysadmins: they often are ahead of netops in terms of automation and
More information about the NANOG