Frage

i an einem Ort arbeiten, wo wir Anwendungen, die verarbeiten und speichern sensible Daten aufzubauen. wir haben 3-Umgebungen. Dev, UAT / QA (Benutzer acceptant Prüfung) und Produktion

Die Entwickler bei meiner Arbeit haben keinen Zugang zu UAT oder Produktion und haben Zugriff auf Dev beschränkt. Alles, was wir in dev tun können, ist zu einem Entwickler DB-Server verbinden. wir haben keinen Zugriff auf den Dev-Server selbst. so dass wir Arent erlaubt mit Dingen wie der Web-Server (IIS) auf dev zu spielen. wenn wir Veränderungen wollen wir gehen müssen, obwohl ein formaler Prozess Arbeitsanforderungen an unsere Netzwerkadministratoren einzureichen (die Tage konnte in Anspruch nimmt). das gleiche gilt, wenn ein Entwickler für etwas zu verlangen, war in einer UAT oder prod Datenbank überprüft werden. diese strenge Zugriffsbeschränkung ist wirklich frustrierend, wenn sie versuchen, unsere Anwendungen zu unterstützen.

ich kann verstehen, warum wir diese Politik haben, da es das Risiko der Dinge reduziert immer vermasselt. aber das macht die Lösung der Probleme wirklich zeitaufwendig und schmerzhaft. etwas, das nur 5 Minuten in Anspruch nehmen könnte zu reparieren (wenn ein Entwickler Zugang hat) könnte Tage dauern, zu lösen.

ist diese Art von strengen Zugriffsrechten normal?

War es hilfreich?

Lösung

Schwer zu sagen, ob es normal ist. Zum Beispiel habe ich für Investmentbanken gearbeitet, wo sie noch mehr drakonischen Verfahren als die, die haben Sie beschreiben. Ich habe arbeitete auch für eine IB, die überhaupt keine Verfahren hatte. Es ist jedoch bemerkenswert, dass die ehemalige noch im Geschäft ist, während die zweite Pleite bekanntlich erst vor kurzem!

Andere Tipps

Es ist kein „dev-Server“, wenn Entwickler keinen Zugriff haben. Jetzt ist es nicht ungewöhnlich 4-Umgebungen zu haben: Produktion, Pre-Produktion, Test und Entwickler. (Sortiert nach Zugang für Entwickler erhöht wird). Wenn ich Namen ignorieren, scheint es, dass Sie die gleiche Struktur außer haben, dass Sie den dev-Server sind vermisst.

Klingt ein wenig eng für mich. Normallly würde ich volle Kontrolle über den Dev-Server erwartet, würde ich glücklich sein Nur-Lese-Zugriff onthe Testserver, um zu sehen und ganz ehrlich zu sein, ich in der Suche auf dem Produktionsserver nicht interessiert bin (von entwicklungspolitischer Sicht).

Natürlich werden die folgenden assumtpions hier gemacht;

  • die drei Umgebungen begann genau die gleiche
  • Änderungen an prod gemacht werden zurück an Entwickler über Test kaskadiert
  • Konfigurationsänderungen in Dev werden von der deployer zu testen und in prod
  • gemacht

In unserem Verfahren hier wir nicht zulassen, dem Entwickler zu Test implementieren -. Dies bis zum Tester ist, bevor wir zu einer dritten Partei übergeben, die prod setzt

Dies bestätigt unsere Freigabeverfahren so viel wie alles andere.

So; solange everythiong für die Freigabe dokumentiert ist, sollten Sie keinen Zugang zu etwas brauchen andere als Dev, aber es wäre schön, ein ordentliches Maß an Kontrolle über die Entwickler-Umgebung zu haben.

Es ist eine Frage, was Sie wollen

Es gibt zwei konkurrierenden Anforderungen bei der Arbeit:

  • Fast Turnaround für Probleme zu beheben / neuen Code zu entwickeln.
  • Um sicherzustellen, dass keine sensiblen Daten durchgesickert erhalten.

Ihr Unternehmen hat (bewusst oder unbewusst) entschieden, dass es besser ist, die Gefahr von undichten sensiblen Daten als zu reduzieren, die Fähigkeit, Probleme zu beheben und neuen Code schnell zu entwickeln. Meine Firma lehnt sich in der gleichen Richtung, ist aber nicht wirklich clued-up genug, um es auf die Spitze nehmen Sie beschreiben.

Dies ist eine Unternehmen Entscheidung.

Es wird gemacht, weil sie (wahrscheinlich unbewusst) Ihr Unternehmen einen höheren Wert auf dem Abwärtsrisiko (undichte Daten) legt als auf dem Aufwärtsrisiko (die Software Arbeit machen). Dies ist eine gemeinsame Bias - es ist bekannt als risikoavers zu sein (ich bin sicher, es gibt einen besseren Begriff als das - jemand), und es ist sehr ärgerlich für diejenigen von uns, und versucht, unsere Arbeit zu erledigen hat zu überwinden eine Reihe von Hindernissen von Menschen setzen dort die kein gutes Verständnis für die Auswirkungen dieser Hindernisse haben.

Zusammengefasst

  • Dies ist ein Unternehmen Entscheidung.
  • Es ist eine Frage, wie unterschiedliche Risiken wahrgenommen werden .
  • Es spiegelt eine risikoavers Position.
  • hat diese Position wahrscheinlich von der Firma angekommen sind ganz unbewusst .

Es geht um Change Management; sicherstellen, dass alle Änderungen an dem System verfolgt werden und es in Release Notes machen, und auch, dass ein Wechsel des Systems in einem Teil verursacht keine Probleme in einem anderen Teil.

Wenn es nach mir ginge, würde ich jedem Entwickler einen PC stark genug geben, wie viele virtuellen Maschinen zu laufen, wie erforderlich, um die Produktionsumgebung, mit totaler Kontrolle über diese Maschinen zu emulieren. Und dann stellen Sie sicher, jede Änderung der offiziellen Entwickler-Umgebung dokumentiert, so dass volle Release Notes hergestellt werden.

Auch in einem kleinen Unternehmen, Ingenieure sollten nicht viel Zugriff auf die Entwickler-Umgebung über Code benötigen. Die Kernumgebung sollte ziemlich statisch bleiben. Welche Arten von Dingen auf dem Web-Server würden Sie in einem rasanten Tempo ändern mögen?

Überprüfen Sie heraus Stackify. Wir soeben einen neuen Service, mit dem Entwickler mehr Sichtbarkeit für ihre Anwendungen und die Produktionsservern gibt. Wir können sie einfach nur den Zugriff auf Dinge wie Protokolldateien, Konfigurationsdateien, Windows-Ereignisanzeige lesen geben, etc. Wir können das Problem lösen, die Sie beschreiben. Wir haben im Grunde DevOps Unterstützung erfunden: http://www.stackify.com

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top