Prozessverbesserung mit DevOps



  • DevOps ist aus der aktuellen Marktanforderung entstanden, anspruchsvolle Kundenerwartungen wie eine hohe Produktqualität oder die pünktliche Fertigstellung von Projekten zu erfüllen. Doch wie lässt sich eine reibungslose Zusammenarbeit von Softwareentwicklung und IT-Betrieb sicherstellen?

    Klicken sie hier um den Artikel zu lesen



  • Hallo Herr Böhlke,

    wie kommen Sie zu Ihrer Feststellung, das die Trennung zwischen Dev und Ops gewährt bleiben soll?

    Auf Ihre Aufklärung freut sich
    Andreas



  • Lieber Herr Zajdziuk,

    ein guter Punkt! Ich möchte den etwas missverständlichen Satz gern auf zwei Ebenen beantworten.

    Auf einer anderen Ebene steht ein Team, das nach DevOps arbeitet, vor der Herausforderung, Incidents/Problems versus Feature-Entwicklungen in der täglichen Arbeit zu priorisieren. Aus meiner Erfahrung heraus lohnt es sich nach einem rollierenden Verfahren im Team einen Teil entwickeln zu lassen und den anderen Teil dediziert für Supporttätigkeiten abzustellen - und zum Beispiel nach einem Sprint durchzutauschen. Somit ist die organisatorische Trennung (oder Systematisierung?) innerhalb des Teams gemeint.

    Aus meiner Erfahrung kommt es in der Praxis nach einiger Zeit dennoch zum Wunsch, das Produkt an den Betrieb zu übergeben, ohne das die Entwicklung weiterhin beteiligt ist. Ich weiß - dies widerspricht der Theorie. Gerade aber zum Ende des Lifecycles ist die Software nicht mehr so interessant für die Weiterentwicklung. Teilweise übernimmt dann ein dediziertes Betriebsteam den Service für die Software. Das Betriebsteam war vielleicht vorher schon an der Entwicklung beteiligt und übernimmt nun als eigenständiger 2nd/3rd Level Support den Betrieb.

    Wie sind Ihre Erfahrungen dahingehend? 

    Ich freue mich auf Ihre Antwort, Lewin



  • Hallo Lewin,

    ich folge Deinem zweiten Absatz, das vor allem größere Unternehmen weiterhin econonic of scale Ansätze verfolgen sollten. Hierbei legt vielleicht ein Qualitätsaudit a la Google einen Maßstab nach der die Applikationsverantwortung an ein Querschnittsteam "Ops", einem Site Reliabiltiy Engineer-Team übergeben wird. Die freiwerdenden Kreativkapazitäten können so neue Werte schaffen, während der Regelbetrieb unauffälliger, "bugfree" Software bequem durch einen zentralen Betrieb alter Tradition verantwortet wird.

    Bei Deinem ersten Absatz irritiert mich zum Einen  die von Dir verwendete Form von DevOps: DevOps ist meiner Meinung nach eine Kultur; keine Einzelperson und auch keine Teilmenge eines IT-Bereichs. Genauso wie ich es äußerst verwirrend finde das eine Stelle als "DevOps Engineer" ausgeschrieben wird, oder das es "DevOps-Tools" geben soll. Es gibt Tools für Repositories, zum Testing, zur Gestaltung eines Workflows ... sie arbeiten allesamt ganz autark, ohne Anwesenheit einer DevOps-Kultur
    https://jaxenter.de/agile-devops-innersource-interview-77536

    Bzgl. Support sehe ich, zumindest in großen Organisationen, unterschiedliche Verantwortlichkeiten: CPU, Storage, Netzwerk, Virtualisierung, Daten & Traffic, etc. und Monitoring, Orchestrierung, Applikationen. Für den (Rest-)Anteil "Applikation" sehe ich  die 100%ige Support-Verantwortung (also inkl. 7x24) beim Entwickler. Dies sorgt ganz schnell und kostengünstigst für "bugfree" Software, abgesehen von den Lerneffekten

     


Log in to reply