Κατασκευή ιστοσελίδας για εταιρεία cloud υπηρεσιών

Η ιστοσελίδα μιας εταιρείας cloud υπηρεσιών πρέπει να βοηθά τον επισκέπτη να αποφασίσει τι μπορεί να μεταφέρει, τι χρειάζεται να παραμείνει όπως είναι και ποιος αναλαμβάνει κάθε κομμάτι λειτουργίας. Οι γενικές υποσχέσεις για «ευελιξία» δεν αρκούν. Ένας τεχνικός ή επιχειρηματικός υπεύθυνος χρειάζεται μοντέλο αξιολόγησης φόρτων, εξαρτήσεων, δεδομένων, αντιγράφων ασφαλείας, μετάβασης και καθημερινής διαχείρισης.

Η είσοδος γίνεται από τον φόρτο και όχι από το προϊόν

Η αρχική σελίδα μπορεί να ζητά από τον επισκέπτη να επιλέξει τι θέλει να φιλοξενήσει ή να μετακινήσει: εφαρμογή, εταιρικό ιστοσελίδα, βάση δεδομένων, αρχεία, περιβάλλον ανάπτυξης ή πολλαπλά συστήματα. Κάθε διαδρομή οδηγεί σε διαφορετικές ερωτήσεις για χρήση, εξαρτήσεις, πρόσβαση και απαιτήσεις λειτουργίας.

Με αυτόν τον τρόπο η εταιρεία αποφεύγει να ξεκινά τη συζήτηση από ονόματα υπηρεσιών που ο πελάτης ίσως δεν γνωρίζει. Η τεχνική κατηγορία εμφανίζεται αφού περιγραφεί το φόρτος εργασίας, δηλαδή ο φόρτος εργασίας ή το σύστημα που πρέπει να λειτουργήσει. Η σελίδα γίνεται εργαλείο διάγνωσης αναγκών.

Φόρτος εργασίας ετοιμότητας πίνακας

Ένα πίνακας ετοιμότητας μπορεί να εξετάζει έξι διαστάσεις: δεδομένα, εφαρμογή, εξαρτήσεις, ταυτότητες χρηστών, δίκτυο και διαδικασία λειτουργίας. Για κάθε διάσταση ο επισκέπτης δηλώνει αν υπάρχει τεκμηρίωση, αν γνωρίζει τον υπεύθυνο και αν υπάρχει περιορισμός που πρέπει να ελεγχθεί. Το αποτέλεσμα δεν είναι αυτόματη «βαθμολογία cloud». Είναι λίστα θεμάτων για τεχνική συζήτηση.

Αυτό το εργαλείο διαφοροποιεί ουσιαστικά την ιστοσελίδα από έναν απλό τιμοκατάλογο υπολογιστικών πόρων. Ο πελάτης αντιλαμβάνεται ότι μια μετάβαση δεν είναι μόνο μεταφορά αρχείων. Περιλαμβάνει εφαρμογές, συνδέσεις με τρίτα συστήματα, δικαιώματα, παρακολούθηση και σχέδιο επαναφοράς αν κάτι δεν λειτουργήσει όπως αναμένεται.

• Δεδομένα και ευαισθησία περιεχομένου
• Εξαρτήσεις από άλλες εφαρμογές ή υπηρεσίες
• Χρήστες, ρόλοι και μέθοδοι πρόσβασης
• Διαδικασία αντίγραφο ασφαλείας, παρακολούθηση και αποκατάστασης

Αποθήκευση και αντίγραφο ασφαλείας δεν είναι το ίδιο πράγμα

Η ιστοσελίδα πρέπει να εξηγεί με απλή γλώσσα ότι η αποθήκευση μιας εφαρμογής δεν ταυτίζεται από μόνη της με στρατηγική αντιγράφων ασφαλείας. Ένα αντίγραφο ασφαλείας χρειάζεται σαφές πεδίο, συχνότητα, διατήρηση και διαδικασία επαναφοράς. Η ακριβής πολιτική εξαρτάται από την υπηρεσία και πρέπει να επιβεβαιώνεται στη σχετική πρόταση ή σύμβαση.

Ένα οδηγός απόφασης μπορεί να ζητά από τον πελάτη ποια δεδομένα πρέπει να μπορούν να ανακτηθούν, ποιος εγκρίνει επαναφορά και ποια είναι η αποδεκτή απώλεια εργασίας σε περίπτωση συμβάντος. Η σελίδα δεν χρειάζεται να δίνει έτοιμες τιμές ή χρόνους. Χρειάζεται να δείχνει ότι το αντίγραφο ασφαλείας είναι λειτουργική απόφαση που πρέπει να σχεδιαστεί.

Πίνακας ευθυνών: ποιος κάνει τι

Στις cloud υπηρεσίες δημιουργείται εύκολα σύγχυση γύρω από την ευθύνη. Ο πάροχος μπορεί να διαχειρίζεται μέρος της υποδομής, ενώ ο πελάτης διατηρεί ευθύνη για λογαριασμούς χρηστών, ρυθμίσεις εφαρμογής ή δεδομένα. Η ιστοσελίδα πρέπει να παρουσιάζει ένα απλό πίνακας ευθυνών ανά υπηρεσία, χωρίς να γενικεύει διαφορετικά μοντέλα.

Ο πίνακας μπορεί να χρησιμοποιεί τρεις στήλες: «πάροχος», «πελάτης», «κοινή διαδικασία». Για κάθε στοιχείο περιγράφεται ποιος αλλάζει ρυθμίσεις, ποιος παρακολουθεί ειδοποιήσεις και ποιος εγκρίνει κρίσιμες ενέργειες. Αυτό μειώνει επικίνδυνα κενά προσδοκιών πριν από την έναρξη συνεργασίας.

Μετάβαση με στάδια και σημεία ελέγχου

Η μετάβαση σε cloud χρειάζεται ξεχωριστή σελίδα που περιγράφει ανακάλυψη, απογραφή, σχεδιασμό, δοκιμή, μεταφορά, επικύρωση και σταθεροποίηση. Δεν είναι σωστό να υπόσχεται ίδιο μονοπάτι για κάθε εφαρμογή. Η σελίδα πρέπει να δείχνει πώς αποφασίζεται αν θα γίνει απλή μεταφορά, αναδιάρθρωση ή παραμονή στο υπάρχον περιβάλλον.

Σε κάθε στάδιο μπορεί να υπάρχει ένα σημείο αποδοχής. Για παράδειγμα, πριν από την τελική αλλαγή επιβεβαιώνονται οι κρίσιμες λειτουργίες και η δυνατότητα επιστροφής στο προηγούμενο περιβάλλον όπου αυτό έχει σχεδιαστεί. Η παρουσία αυτών των σημεία ελέγχου δείχνει διαδικασία και κάνει τον κίνδυνο ορατό αντί να τον κρύβει πίσω από τη λέξη «μετάβαση».

Λειτουργία μετά το έναρξη παραγωγικής λειτουργίας

Η πώληση δεν τελειώνει όταν ξεκινήσει το νέο περιβάλλον. Η ιστοσελίδα χρειάζεται να εξηγεί τι σημαίνει διαχειριζόμενη ή διαχειριζόμενη υπηρεσία στην πράξη: παρακολούθηση, ενημερώσεις, διαχείριση περιστατικών, αλλαγές, αντίγραφο ασφαλείας και αναφορές, μόνο εφόσον αυτά αποτελούν πραγματικό μέρος της προσφοράς. Δεν πρέπει να συνδυάζονται διαφορετικά επίπεδα εξυπηρέτησης σε μία ασαφή υπόσχεση.

Για υπηρεσίες όπου ο πελάτης διαχειρίζεται περισσότερα στοιχεία μόνος του, η σελίδα μπορεί να εξηγεί ποια εργαλεία και τεκμηρίωση παρέχονται. Η σαφής επιλογή μοντέλο λειτουργίας βοηθά τον αγοραστή να συγκρίνει προτάσεις με βάση τον καθημερινό φόρτο που παραμένει στην εσωτερική του ομάδα.

Ασφάλεια ως σύνολο ελέγχων, όχι ως εικονίδιο

Η σελίδα ασφάλειας πρέπει να περιγράφει επαληθεύσιμες πρακτικές που πράγματι εφαρμόζονται, χωρίς απόλυτες διαβεβαιώσεις. Μπορεί να οργανώνει την πληροφορία σε ταυτότητες, πρόσβαση, καταγραφή ενεργειών, ενημερώσεις, αντίγραφα και αντιμετώπιση συμβάντων. Όπου υπάρχουν πραγματικές πιστοποιήσεις ή πολιτικές, παρουσιάζονται με σαφή πεδίο εφαρμογής.

Αν δεν υπάρχει τεκμηριωμένη πληροφορία για συγκεκριμένο έλεγχο, δεν πρέπει να εφευρεθεί για χάρη του προωθητική επικοινωνία. Αντίθετα, η ιστοσελίδα μπορεί να δίνει ερωτηματολόγιο ασφάλειας που συμπληρώνεται κατά την αξιολόγηση. Αυτό βοηθά οργανισμούς με ειδικές απαιτήσεις να πάρουν γραπτές απαντήσεις πριν από την ανάθεση.

Κόστος με παράγοντες και όχι ψευδή απλότητα

Το cloud κόστος εξαρτάται από πόρους, χρήση, αποθήκευση, μεταφορά δεδομένων, επίπεδο διαχείρισης και άλλες παραμέτρους ανά υπηρεσία. Αν δεν υπάρχουν σταθερές δημόσιες τιμές, είναι προτιμότερο η ιστοσελίδα να εξηγεί τους βασικούς παράγοντες κόστους και να ζητά πραγματικά στοιχεία για εκτίμηση. Ένας πρόχειρος αριθμός μπορεί να οδηγήσει σε λάθος σύγκριση.

Ένα υπολογιστής εκτίμησης μπορεί να είναι χρήσιμο μόνο όταν οι παραδοχές του είναι ορατές και ενημερώνονται από πραγματικά δεδομένα. Διαφορετικά, ένα δομημένη σύνοψη απαιτήσεων με εύρος χρηστών, μέγεθος δεδομένων, ώρες λειτουργίας και απαιτούμενη διαχείριση είναι πιο τίμιο και πιο χρήσιμο για μια πρώτη πρόταση.

Έλεγχος κινδύνων ανασκόπηση πριν δοθεί έγκριση

Η επιχείρηση πρέπει να εξετάσει τι θα συμβεί αν αποτύχει μια εξάρτηση, αν χαθεί πρόσβαση, αν χρειαστεί επαναφορά δεδομένων ή αν η εφαρμογή δεν συμπεριφερθεί όπως στη δοκιμή. Η ιστοσελίδα μπορεί να δίνει κινδύνων ανασκόπηση με ερωτήσεις και όχι υποσχέσεις. Κάθε απάντηση γίνεται θέμα που πρέπει να κλείσει πριν από το έναρξη παραγωγικής λειτουργίας.

Επίσης αξίζει να υπάρχει ερώτηση εξόδου: πώς παραδίδονται δεδομένα και τεκμηρίωση αν η συνεργασία τερματιστεί; Αυτή η πληροφορία δεν είναι αρνητική για την πώληση. Αντίθετα, δείχνει ότι ο πάροχος αντιμετωπίζει τον κύκλο ζωής της υπηρεσίας με ώριμο τρόπο.

• Τι εξαρτήσεις μπορεί να σταματήσουν τη λειτουργία;
• Πώς δοκιμάζεται η επαναφορά αντιγράφων;
• Ποιος εγκρίνει κρίσιμες αλλαγές;
• Πώς προβλέπεται μελλοντική έξοδος ή μεταφορά;

Η προτροπή πρέπει να ξεκινά από τεχνική αξιολόγηση

Η κατασκευή ιστοσελίδας για εταιρεία cloud υπηρεσιών είναι πιο αποτελεσματική όταν καταλήγει σε «Αξιολόγηση φόρτου» αντί σε αόριστο «Ζητήστε προσφορά». Η φόρμα μπορεί να ζητά είδος συστήματος, εξαρτήσεις, δεδομένα σε γενικές κατηγορίες, χρήστες και επιθυμητό μοντέλο λειτουργίας χωρίς να ζητά κωδικούς ή εμπιστευτική τεχνική πληροφορία.

Μετά την υποβολή, ο ενδιαφερόμενος πρέπει να ξέρει ότι ακολουθεί διερεύνηση και όχι αυτόματη δέσμευση. Η σωστή ιστοσελίδα κάνει ορατό το έργο που προηγείται μιας ασφαλούς μετάβασης και μεταφέρει τη συζήτηση από τα αόριστα οφέλη στις πραγματικές αποφάσεις λειτουργίας.

Σχετικό περιεχόμενο

Ιστοσελίδα για εταιρεία πληροφορικής Ιστοσελίδα για τεχνική εταιρεία

Επόμενο βήμα

Ξεκινήστε με φόρτος εργασίας αξιολόγηση και πίνακας ευθυνών. Όταν είναι σαφή οι εξαρτήσεις και οι ευθύνες, η ιστοσελίδα μπορεί να οδηγήσει σε ώριμη τεχνική αξιολόγηση αντί για πρόχειρη προσφορά.